public inbox for [email protected]
help / color / mirror / Atom feedFrom: Zubkovsky, Sergey <[email protected]>
To: Andrew Dunstan <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Cc: Gregory Stark <[email protected]>
Cc: [email protected]
Cc: Magnus Hagander <[email protected]>
Subject: Re: [DOCS] pg_total_relation_size() and CHECKPOINT
Date: Fri, 28 Mar 2008 18:43:29 +0300
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
It seems I've found the cause and the workaround of the problem.
MSVC's stat() is implemented by using FindNextFile().
MSDN contains the following suspicious paragraph аbout FindNextFile():
"In rare cases, file attribute information on NTFS file systems may not be current at the time you call this function. To obtain the current NTFS file system file attributes, call GetFileInformationByHandle."
Since we generally cannot open an examined file, we need another way.
In the prepared custom build of PG 8.3.1 the native MSVC's stat() was rewrote by adding GetFileAttributesEx() to correct stat's st_size value.
I had seen that a result of MSVC's stat() and a result of GetFileAttributesEx() may be differ by the file size values at least.
The most important thing is the test in the original post
( http://archives.postgresql.org/pgsql-docs/2008-03/msg00041.php )
doesn't reproduce any inconsistence now.
All work fine.
This was tested on my WinXP SP2 platform but I suppose it will work on any NT-based OS.
Thanks,
Sergey Zubkovsky
-----Original Message-----
From: Andrew Dunstan [mailto:[email protected]]
Sent: Thursday, March 27, 2008 3:54 PM
To: Zubkovsky, Sergey
Cc: Tom Lane; Alvaro Herrera; Gregory Stark; [email protected]; Magnus Hagander
Subject: Re: [HACKERS] [DOCS] pg_total_relation_size() and CHECKPOINT
Zubkovsky, Sergey wrote:
> 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.
>
>
>
Yes, but we immediately follow the lseek bye a write(). See
src/backend/storage/smgr/md.c:mdextend() .
cheers
andrew
view thread (24+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: [DOCS] pg_total_relation_size() and CHECKPOINT
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox