Re: Proposal: Snapshot cloning

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jim Nasby <decibel(at)decibel(dot)org>
Cc: "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Jan Wieck" <JanWieck(at)Yahoo(dot)com>, "Hannu Krosing" <hannu(at)skype(dot)net>, "PostgreSQL Development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: Snapshot cloning
Date: 2007-01-30 04:28:52
Message-ID: 24805.1170131332@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jim Nasby <decibel(at)decibel(dot)org> writes:
> On Jan 26, 2007, at 4:48 PM, Tom Lane wrote:
>> I don't actually see that it buys you a darn thing ... you still won't
>> be able to delete dead updated tuples because of the possibility of
>> the LRT deciding to chase ctid chains up from the tuples it can see.

> Well, Simon was talking about a serialized LRT, which ISTM shouldn't
> be hunting down ctid chains past the point it serialized at.

How you figure that? If the LRT wants to update a tuple, it's got to
chase the ctid chain to see whether the head update committed or not.
It's not an error for a serializable transaction to update a tuple that
was tentatively updated by a transaction that rolled back.

> Even if that's not the case, there is also the possibility if a LRT
> publishing information about what tables it will hit.

I think we already bought 99% of the possible win there by fixing
vacuum. Most ordinary transactions aren't going to be able to predict
which other tables the user might try to touch.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message A. Kretschmer 2007-01-30 06:32:11 Re: SQL to get a table columns comments?
Previous Message Bruce Momjian 2007-01-30 04:02:37 Re: Modifying and solidifying contrib