Message-ID: <47EB13BF.8080301@dunslane.net>
Date: Wed, 26 Mar 2008 23:25:51 -0400
From: Andrew Dunstan <andrew@dunslane.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.8.0.12) Gecko/20071019 Fedora/1.0.9-3.fc6 pango-text
	SeaMonkey/1.0.9
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Alvaro Herrera <alvherre@commandprompt.com>,
	Gregory Stark <stark@enterprisedb.com>,
	"Zubkovsky, Sergey" <Sergey.Zubkovsky@transas.com>,
	pgsql-hackers@postgresql.org, Magnus Hagander <magnus@hagander.net>
Subject: Re: [DOCS] pg_total_relation_size() and CHECKPOINT
References: <528853D3C5ED2C4AA8990B504BA7FB850106DF14@sol.transas.com>
	<21561.1205515308@sss.pgh.pa.us>
	<87myp1f9a7.fsf@oxford.xeocode.com>
	<24576.1205524921@sss.pgh.pa.us>
	<20080326132250.GK5895@alvh.no-ip.org>
	<47EA5602.6060605@dunslane.net> <21662.1206546092@sss.pgh.pa.us>
	<47EAE45D.8050902@dunslane.net> <21044.1206580136@sss.pgh.pa.us>
In-Reply-To: <21044.1206580136@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


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.
>
> 			
>   

OK, a very large insert failed as expected. Checkpoint succeeded. Then 
vacuum recovered the space.

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.

cheers

andrew