Maybe this helps: "It is not an error to set a file pointer to a position beyond the end of the file. The size of the file does not increase until you call the SetEndOfFile, WriteFile, or WriteFileEx function. A write operation increases the size of the file to the file pointer position plus the size of the buffer written, which results in the intervening bytes uninitialized."
http://msdn2.microsoft.com/en-us/library/aa365541(VS.85).aspx According to Windows' lseek implementation (attached) SetEndOfFile() isn't called for this case. Thanks, Sergey Zubkovsky -----Original Message----- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Thursday, March 27, 2008 7:14 AM To: Andrew Dunstan Cc: Alvaro Herrera; Gregory Stark; Zubkovsky, Sergey; pgsql-hackers@postgresql.org; Magnus Hagander Subject: Re: [HACKERS] [DOCS] pg_total_relation_size() and CHECKPOINT Andrew Dunstan <[EMAIL PROTECTED]> writes: > 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. Hmm. If it really works that way, one would hope Microsoft would've documented that someplace. Can anyone find a statement that Windows' stat() is not current? regards, tom lane
lseek.c
Description: lseek.c
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
