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

From Tom Lane
Subject Re: [DOCS] pg_total_relation_size() and CHECKPOINT
Date
Msg-id 21044.1206580136@sss.pgh.pa.us
Whole thread Raw
In response to Re: [DOCS] pg_total_relation_size() and CHECKPOINT  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: [DOCS] pg_total_relation_size() and CHECKPOINT
Re: [DOCS] pg_total_relation_size() and CHECKPOINT
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> 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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: [DOCS] pg_total_relation_size() and CHECKPOINT
Next
From: Andrew Dunstan
Date:
Subject: Re: [DOCS] pg_total_relation_size() and CHECKPOINT