Re: Nested transactions: low level stuff

Sorry I have a basic question.
Was there any consensus we would introduce nested transactions
(or savepoints) in the way currently discussed ?

regards,
Hiroshi Inoue

Manfred Koizar wrote:
> 
> On Wed, 19 Mar 2003 13:00:07 -0500, Tom Lane <tgl@sss.pgh.pa.us>
> wrote:
> >Manfred Koizar <mkoi-pg@aon.at> 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 majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly

-- 
Hiroshi Inouehttp://www.geocities.jp/inocchichichi/psqlodbc/