public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Gregory Stark <[email protected]>
Cc: Zubkovsky, Sergey <[email protected]>
Cc: [email protected]
Subject: Re: [DOCS] pg_total_relation_size() and CHECKPOINT
Date: Fri, 14 Mar 2008 16:02:01 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>

Gregory Stark <[email protected]> writes:
> "Tom Lane" <[email protected]> writes:
>> 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?

What I'm afraid of is write() returning ENOSPC for a write to a disk
block we thought we had allocated previously.  If such a situation is
persistent we'd be unable to flush dirty data from shared buffers and
thus never be able to complete a checkpoint.  We'd never *get* to the
fsync, so whether the data is safe after fsync is moot.

The way it is supposed to work is that ENOSPC ought to happen during
smgrextend, that is before we've put any data into a shared buffer
corresponding to a new page of the file.  With that, we will never be
able to commit a transaction that requires disk space we don't have.

The real question here is whether Windows' stat() is telling the truth
about how much filesystem space has actually been allocated to a file.
It seems entirely possible that it's not; but if it is, then I think we
have a problem.

			regards, tom lane

view thread (24+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: [DOCS] pg_total_relation_size() and CHECKPOINT
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox