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

From Andrew Dunstan
Subject Re: [DOCS] pg_total_relation_size() and CHECKPOINT
Date
Msg-id 47EB0850.1050805@dunslane.net
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

Tom Lane wrote:
> 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.
>
>     
>   

I'm working on this (thank goodness for junctions). Maybe we shopuld 
look at providing a config setting for pg_xlog.

cheers

andrew


pgsql-hackers by date:

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