Re: Proposal: Snapshot cloning

From: Jim Nasby <decibel(at)decibel(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 02:00:56
Message-ID: E029C51F-314C-41C8-89C3-3F1E34313F93@decibel.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Jan 26, 2007, at 4:48 PM, Tom Lane wrote:
> "Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
>> You got me. My description was too loose, but you also got the rough
>> picture. We'll save the detail for another day, but we all know its a
>> bridge we will have to cross one day, soon. I wasn't meaning to raise
>> this specific discussion now, just to say that publishing
>> snapshots for
>> known LRTs is one way by which we can solve the LRT/VACUUMing issue.
>
> 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. You
> also seem to be assuming that a transaction can have only one
> snapshot,
> which is not something we can enforce in enough cases to make it a
> very
> useful restriction.

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

Even if that's not the case, there is also the possibility if a LRT
publishing information about what tables it will hit. Any tables not
being touched by a LRT could be vacuumed past the global minxid. It
would be up to the user to do that in many cases, but that's likely
to be well worth it if you have LRTs that are only hitting a few
tables yet you have other tables that really, really need to stay
vacuumed. Believe me, that is a very common use case in the real
world (think queue table, or web session table).
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2007-01-30 02:07:44 Re: No ~ operator for box, point
Previous Message Andrew Dunstan 2007-01-30 01:52:26 Re: Modifying and solidifying contrib