Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 246B12E006F for ; Wed, 26 Mar 2008 22:09:23 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 76640-05 for ; Wed, 26 Mar 2008 22:09:10 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 8595D2E0064 for ; Wed, 26 Mar 2008 22:09:18 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id m2R18vJb021045; Wed, 26 Mar 2008 21:08:57 -0400 (EDT) To: Andrew Dunstan cc: Alvaro Herrera , Gregory Stark , "Zubkovsky, Sergey" , pgsql-hackers@postgresql.org, Magnus Hagander Subject: Re: [DOCS] pg_total_relation_size() and CHECKPOINT In-reply-to: <47EAE45D.8050902@dunslane.net> 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> Comments: In-reply-to Andrew Dunstan message dated "Wed, 26 Mar 2008 20:03:41 -0400" Date: Wed, 26 Mar 2008 21:08:56 -0400 Message-ID: <21044.1206580136@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200803/1088 X-Sequence-Number: 115889 Andrew Dunstan 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