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

From Bruce Momjian
Subject Re: Nested transactions: low level stuff
Date
Msg-id 200303211518.h2LFIG926809@candle.pha.pa.us
Whole thread Raw
In response to Re: Nested transactions: low level stuff  ("Vadim Mikheev" <vmikheev@reveredata.com>)
Responses Re: Nested transactions: low level stuff  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Vadim Mikheev 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?
> 
> Don't mess up things, Bruce - UNDO is not for subtransactions only!
> UNDO would allow immediate storage cleanup and vacuum would
> not be required anymore. Subtransactions/savepoints would be just
> "by-effect" of UNDO. (And, btw, how would you implement "implicit"
> savepoints with "separate subtrans id" approach?)
> 
> But do we need any voting, actually? Is there anybody who want/ready
> implement UNDO functionality? No? Then there is nothing to vote about.
> (Though I personally consider "subtrans id-s" as "messing up messy
> transaction system". Messing up is always easier then re-designing).

Yes, Vadim is right.  The UNDO was much more than subtransactions, but
actually a discussion comparing UNDO and the free-space map approach.

It would help with subtransactions, but it is only tangentially related.

I think the issue was:
Do we want UNDO or FSM?

We chose FSM but UNDO is still an option.
Do we want UNDO just for subtransactions?

That was pretty easily defeated, though I made an argument that you
could do UNDO pretty cheaply when you have WAL ensuring crash recovery.

--  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: A bad behavior under autocommit off mode
Next
From: Christoph Haller
Date:
Subject: Re: timestamp/date in ecpg