On Wed, 19 Mar 2003 13:00:07 -0500, Tom Lane <[EMAIL PROTECTED]> wrote: >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 >needed.
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 ... Servus Manfred ---------------------------(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
