From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, Patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: subtransactions -- storage manager |
Date: | 2004-04-30 00:02:06 |
Message-ID: | 200404300002.i3U026n13367@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Simon Riggs wrote:
> On Sun, 2004-04-25 at 19:06, Alvaro Herrera wrote:
> > Hackers,
> >
> > This patch adds subtransaction support into the storage manager. Files
> > created or dropped inside a subtransaction are correctly dealt with at
> > subtransaction commit or abort.
>
> > - pg_clog/pg_subtrans. Need a solution.
> >
> >
> > PS: somehow I managed to get tired of the phrase "nested transactions"
> > and I'm using the term "subtransactions" instead. In my head they are
> > the same thing ...
>
> Impressive.
>
> As you're aware, our current work overlaps.
> pg_clog doesn't seem like the place to record subtransactions, though
> maybe it is... could we not give subtransactions a txnid just as with
> flat transactions? That way we can record everything in pg_clog AND
> recovery will work without further modification - as long as the failure
> of a top level transaction causes failure of every subtransaction EVEN
> if the subtrans originally committed.
The problem is we have to atomically mark multiple transactions as
committed/aborted in pg_clog. Each subtransaction does get its own xid,
it is just that pg_subtrans maps each xid to is parent xid for use in
atomically marking the xids as committed/aborted.
Recovery via xlog should be fine.
> If you add pg_subtrans, you will need to make recovery work all over
> again...really, you don't want to be doing that, do you?
>
> I also have other questions....
> Forgive my lack of attention: I want SAVEPOINTs, not subtransactions...
> how do we do those?
Savepoints are basically just a BEGIN at the save point, and a ROLLBACK
to get you back to the saved spot. It is just window-dressing on top of
nested transactions.
> My last focus on this was to do with SQL handling of transactional
> rollback characteristics on error. PostgreSQL performs rollback on
> complete txn when error occurs, rather than allowing statement level
> abort and then retry...this was characterised as requiring "nested
> transactions"...are your aware of this...is it on your roadmap.
Yes, that is the whole point --- to allow individual queries to fail
without rolling back the entire transaction.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2004-04-30 01:58:49 | Re: PITR Phase 1 - Full set of patches |
Previous Message | Sean Chittenden | 2004-04-29 23:00:42 | Re: SECURITY DEFINER not being propagated... |