Re: [PATCH] Lazy xid assingment V2

From: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
To: August Zajonc <augustz(at)augustz(dot)com>, Postgresql-Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Lazy xid assingment V2
Date: 2007-09-01 01:24:28
Message-ID: 46D8BF4C.5040107@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

August Zajonc wrote:
I assume that you meant that mail to go to pgsql-hackers too, and just
clicked the wrong button by accident. If not, please forgive that
I post the reply to the list.

> Are you going to look at putting temp relations into a special folder
> for 8.4? I really like that idea for crash cleanup and generally.
According to Alvaro, that is already the case. I didn't check, though.

> For non temp files, can they be created in a pending folder, work done
> on them, and then moved over to final destination just before commit?
Hm... that doesn't sound bad at first sight. We'd need one such folder
per tablespace, though.

> You could still leak them (ie, you move to final location and bail
> before commit) but it seems to narrow the window down significantly.
That leak could be prevented I think if the COMMIT record indicated
which files are to be moved, and the actual move happens after the
flushing the COMMIT record to disk. Probably the move would need to
happen while we're in the commit critical section too, to guard
against concurrent checkpoints - but that all seems doable.

> Actually, as I write this, a bad idea, the temp files are the low
> hanging fruit, don't think it's worth dealing with non-temp files until
> you can make it totally leakproof.
There is no fundamental difference between temporary and non-temporary
delete-on-abort files I think. There is one for delete-on-commit files,
(and only because of asynchronous commits)
but the leakage possibility for those is already really small (I'd
take a COMMIT, a crash *and* a CHECKPOINT at just the right time to
get a leak).

The hardest part seems to be making the code cope with moved files.
Though we only need to care about that local backend I believe, because
all others haven't yet seen the files anyway.

greetings, Florian Pflug

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Florian G. Pflug 2007-09-01 01:42:44 Re: [PATCH] Lazy xid assingment V2
Previous Message Tom Lane 2007-09-01 00:46:01 Re: [PATCH] Lazy xid assingment V2