[mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 29, 2008 4:54 PM
To: Zubkovsky, Sergey
Cc: Andrew Dunstan; Tom Lane; Alvaro Herrera; Gregory Stark;
[EMAIL PROTECTED]
Subject: Re: [HACKERS] [DOCS] pg_total_relation_size() and CHECKPOINT
I already applied a different patch for this quite some time ago
Zubkovsky, Sergey wrote:
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 le
h 28, 2008 6:43 PM
To: Andrew Dunstan
Cc: Tom Lane; Alvaro Herrera; Gregory Stark; pgsql-hackers@postgresql.org;
Magnus Hagander
Subject: RE: [HACKERS] [DOCS] pg_total_relation_size() and CHECKPOINT
It seems I've found the cause and the workaround of the problem.
MSVC's stat() is implem
54 PM
To: Zubkovsky, Sergey
Cc: Tom Lane; Alvaro Herrera; Gregory Stark; pgsql-hackers@postgresql.org;
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 t
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Andrew Dunstan wrote:
I'm working on this (thank goodness for junctions). Maybe we shopuld
look at providing a config setting for pg_xlog.
I hope you mean an initdb switch -- otherwise it is way too easy to
misus
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>> I'm working on this (thank goodness for junctions). Maybe we shopuld
>> look at providing a config setting for pg_xlog.
> I hope you mean an initdb switch -- otherwise it is way too easy to
> misuse.
There's one already ..
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 fil
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
An
Andrew Dunstan wrote:
> I'm working on this (thank goodness for junctions). Maybe we shopuld
> look at providing a config setting for pg_xlog.
I hope you mean an initdb switch -- otherwise it is way too easy to
misuse.
--
Alvaro Herrerahttp://www.CommandPrompt.
On Thu, 27 Mar 2008 00:13:42 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> 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 a
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
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 r
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 r
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
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Alvaro Herrera wrote:
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.
It seems entirely possible that it's n
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> 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.
>>> It seems entirely possible that it's not; but if it is, the
, March 26, 2008 4:56 PM
To: Alvaro Herrera
Cc: Tom Lane; Gregory Stark; Zubkovsky, Sergey;
pgsql-hackers@postgresql.org; Magnus Hagander
Subject: Re: [HACKERS] [DOCS] pg_total_relation_size() and CHECKPOINT
Alvaro Herrera wrote:
> Tom Lane wrote:
>
>
>> The real question here
Alvaro Herrera wrote:
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.
It seems entirely possible that it's not; but if it is, then I think we
have a problem.
Has this been e
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.
> It seems entirely possible that it's not; but if it is, then I think we
> have a problem.
Has this been examined by a Windows hacker?
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Hmm. I find the whole thing fairly worrisome, because what it suggests
>> is that Windows isn't actually allocating file space during smgrextend,
>> which would mean that we'd be prone to running out of disk spac
"Tom Lane" <[EMAIL PROTECTED]> writes:
> "Zubkovsky, Sergey" <[EMAIL PROTECTED]> writes:
>> The previous results were received on PG 8.3 version:
>> "PostgreSQL 8.3.0, compiled by Visual C++ build 1400"
>
> Hmm. I find the whole thing fairly worrisome, because what it suggests
> is that Wind
"Zubkovsky, Sergey" <[EMAIL PROTECTED]> writes:
> The previous results were received on PG 8.3 version:
> "PostgreSQL 8.3.0, compiled by Visual C++ build 1400"
Hmm. I find the whole thing fairly worrisome, because what it suggests
is that Windows isn't actually allocating file space during
The previous results were received on PG 8.3 version:
"PostgreSQL 8.3.0, compiled by Visual C++ build 1400"
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Friday, March 14, 2008 7:19 PM
To: Zubkovsky, Sergey
Cc: [EMAIL PROTECTED]; pgsql-hackers@postgresql.org
[ moved to -hackers --- see original thread here
http://archives.postgresql.org/pgsql-docs/2008-03/msg00039.php
]
"Zubkovsky, Sergey" <[EMAIL PROTECTED]> writes:
> Here is my example.
Hmm ... on my Fedora machine I get the same result (704512) in
all these cases, which is what I'd expect. (The e
24 matches
Mail list logo
