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
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 |