On Wed, 19 Mar 2003 13:00:07 -0500, Tom Lane <[EMAIL PROTECTED]>
>Manfred Koizar <[EMAIL PROTECTED]> writes:
>> And if the change is lost, it can
>> be redone by the next backend visiting the tuple.
>Not if the subtransaction log state has been removed as no longer

But this problem is not triggered by a tuple that has its xmin changed
by a visitor and then looses that change again.  We'd have the same
problems with tuples that have never been visited (*).  So we must
make sure that pg_subtrans segments are not discarded as long as they
are needed.  

(*) I guess your argument is:  VACUUM makes sure that all tuples have
been visited before it discards pg_subtrans segments.

With my 4-state-proposal VACUUM can decide whether a pg_subtrans
segment is still needed by only looking at pg_clog.

>  I think a WAL entry will be essential.

I'm still in doubt, but it's moot (see below).

>I think we'd be a lot better off to design this so that we don't need to
>alter heap tuple xmin values...

If Vadim remembers correctly we cannot safely change xmin, unless we
want to grab a write lock.  Ok, we'll not change xmin and we'll not
set the commit bit before xmin is visible to all if xmin is a
subtransaction.  We can always add this performance hack later, if
someone finds a safe implementation ...


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Reply via email to