On Jan 26, 2007, at 4:48 PM, Tom Lane wrote:
> "Simon Riggs" <simon@2ndquadrant.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@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)