Re: [DOCS] pg_total_relation_size() and CHECKPOINT - Mailing list pgsql-hackers

From Zubkovsky, Sergey
Subject Re: [DOCS] pg_total_relation_size() and CHECKPOINT
Date
Msg-id 528853D3C5ED2C4AA8990B504BA7FB850106DF2A@sol.transas.com
Whole thread Raw
In response to Re: [DOCS] pg_total_relation_size() and CHECKPOINT  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [DOCS] pg_total_relation_size() and CHECKPOINT
List pgsql-hackers
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:tgl@sss.pgh.pa.us]
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 <andrew@dunslane.net> 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

Attachment

pgsql-hackers by date:

Previous
From: Zdenek Kotala
Date:
Subject: Re: Script binaries renaming
Next
From: Andrew Dunstan
Date:
Subject: Re: [DOCS] pg_total_relation_size() and CHECKPOINT