To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Zubkovsky\, Sergey" <Sergey.Zubkovsky@transas.com>,
	<pgsql-hackers@postgresql.org>
Subject: Re: [DOCS] pg_total_relation_size() and CHECKPOINT
In-Reply-To: <21561.1205515308@sss.pgh.pa.us> (Tom Lane's message of "Fri\,
	14 Mar 2008 13\:21\:48 -0400")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
References: <528853D3C5ED2C4AA8990B504BA7FB850106DF14@sol.transas.com>
	<21561.1205515308@sss.pgh.pa.us>
From: Gregory Stark <stark@enterprisedb.com>
Organization: EnterpriseDB
Date: Fri, 14 Mar 2008 18:30:24 +0000
Message-ID: <87myp1f9a7.fsf@oxford.xeocode.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> "Zubkovsky, Sergey" <Sergey.Zubkovsky@transas.com> 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 smgrextend,
> which would mean that we'd be prone to running out of disk space at
> unfortunate times --- like during a checkpoint, after we've already
> promised the client the data is committed.

Surely we can't lose after the fsync? Losing at commit rather than at the time
of insert might still be poor, but how could we lose after we've promised the
data is committed?

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Ask me about EnterpriseDB's Slony Replication support!