Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
