Re: Nested transactions: low level stuff - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Nested transactions: low level stuff
Date
Msg-id 200303210426.h2L4Qdo18926@candle.pha.pa.us
Whole thread Raw
In response to Re: Nested transactions: low level stuff  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
I found the discussion, all 146 messages:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=200105231527.f4NFRvG07790%40candle.pha.pa.us&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DISO-8859-1%26q%3Dvote%2Bsubtransaction%26btnG%3DGoogle%2BSearch%26meta%3Dgroup%253Dcomp.databases.postgresql.*

The discussion was more general and dealt with vacuum and undo.

The basic discussion for subtransactions is whether you want to add UNDO
logic just to do subtransactions, or whether it is easier to deal with
multiple transaction ids per backend.  Most thought the the second
option was much easier.

In fact, I had proposed a simpler UNDO capability that revisited tuples
and set their XID to a fixed aborted XID to clean up aborted
subtransactions, but most now like the multiple XID solution.

---------------------------------------------------------------------------

Bruce Momjian wrote:
> 
> If there was no official vote, the conclusion came from the discussion
> that almost everyone wanted subtransactions without UNDO.
> 
> I don't want to rehash it.  If you want a vote, let's vote.
> 
> Who wants subtransactions with UNDO and who wants it with a separate
> transaction id for every subtransaction?
> 
> ---------------------------------------------------------------------------
> 
> Hiroshi Inoue wrote:
> > Bruce Momjian wrote:
> > > 
> > > Hiroshi Inoue wrote:
> > > > Bruce Momjian wrote:
> > > > >
> > > > > Hiroshi Inoue wrote:
> > > > > > > > Vadim planned to implement the savepoints functionality
> > > > > > > > using UNDO mechanism. AFAIR it was never denied explicitly.
> > > > > > >
> > > > > > > If you go to the TODO.detail/transactions archive, there was discussion
> > > > > > > of using UNDO, and most felt that there were too many problems of having
> > > > > > > to manage the undo system,
> > > > > >
> > > > > > This is closely related to the basics of PostgreSQL.
> > > > > > Pleas don't decide it implicitly.
> > > > >
> > > > > We took a vote and UNDO lost --- do you want to do another vote?
> > > >
> > > > Sorry I missed the vote. Where is it ?
> > > 
> > > I can't find the vote in the archive.  As I remember, Vadim and a few
> > > others liked UNDO, while more liked the current approach.
> > 
> > As far as I remember there was no such vote or decision.
> > Note that I'm not particularly on UNDO side but I don't
> > think that the currently discussed way is much better
> > than UNDO. Please make the advantage/disadvantages clear
> > and let me understand the meaning of this thread.
> > 
> > regards,
> > Hiroshi Inoue
> >     http://www.geocities.jp/inocchichichi/psqlodbc/
> > 
> 
> -- 
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 359-1001
>   +  If your life is a hard drive,     |  13 Roberts Road
>   +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
> 
> http://www.postgresql.org/docs/faqs/FAQ.html
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Nested transactions: low level stuff
Next
From: "Christopher Kings-Lynne"
Date:
Subject: date index problems