Re: [DOCS] pg_total_relation_size() and CHECKPOINT

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Zubkovsky\, Sergey" <Sergey(dot)Zubkovsky(at)transas(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [DOCS] pg_total_relation_size() and CHECKPOINT
Date: 2008-03-14 18:30:24
Message-ID: 87myp1f9a7.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs pgsql-hackers

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> "Zubkovsky, Sergey" <Sergey(dot)Zubkovsky(at)transas(dot)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!

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Tom Lane 2008-03-14 20:02:01 Re: [DOCS] pg_total_relation_size() and CHECKPOINT
Previous Message Alvaro Herrera 2008-03-14 17:28:39 Re: Small typo in install-win32.sgml

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2008-03-14 18:31:09 Re: Commit fest?
Previous Message Devrim GÜNDÜZ 2008-03-14 18:05:36 Re: [COMMITTERS] pgsql: Fix vacuum so that autovacuum is really not cancelled when doing