Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>
>> Tom Lane wrote:
>>
>>>> The real question here is whether Windows' stat() is telling the truth
>>>> about how much filesystem space has actually been allocated to a file.
>>>>
>>> One thing that would be good is just to see who else can reproduce
>>> the original observation:
>>> http://archives.postgresql.org/pgsql-docs/2008-03/msg00041.php
>>>
>
>
>> I have reproduced it in XP-Pro/SP2 running in a VMWare machine on an FC6
>> host.
>>
>
> OK, so the next question is do we really have an issue, or is this just
> an observational artifact? What I'd try is deliberately running the
> machine out of disk space with a long series of inserts, and then see
> whether subsequent checkpoint attempts fail due to ENOSPC errors while
> trying to write out dirty buffers.
>
> To avoid conflating this effect with anything else, it'd be best if you
> could put the DB on its own small partition, and *not* put pg_xlog
> there.
>
>
>
OK, a very large insert failed as expected. Checkpoint succeeded. Then
vacuum recovered the space.
I suspect that the size reported by stat() is a little delayed here, but
the file system is keeping proper track of it, so the lseek that tries
to extend the file fails at the right spot.
cheers
andrew