From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: chained transactions |
Date: | 2018-07-17 17:21:20 |
Message-ID: | b989871c-b2d9-42b9-4461-ace590d1a7c0@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 01/03/18 05:35, Peter Eisentraut wrote:
> The SQL standard offers the "chained transactions" feature to address
> this. The new command variants COMMIT AND CHAIN and ROLLBACK AND CHAIN
> immediately start a new transaction with the characteristics (isolation
> level, read/write, deferrable) of the previous one. So code that has
> particular requirements regard transaction isolation and such can use
> this to simplify code management.
Oh, is that all it does? That's disappointing, because that's a lot less
powerful than how I understand chained transactions. And at the same
time relieving, because that's a lot simpler to implement :-).
In Gray & Reuter's classic book, Transaction Processing, they describe
chained transactions so that you also keep locks and cursors.
Unfortunately I don't have a copy at hand, but that's my recollection,
at least. I guess the SQL standard committee had a different idea.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2018-07-17 17:27:48 | Re: PG 10: could not generate random cancel key |
Previous Message | Robert Haas | 2018-07-17 17:15:08 | Re: PG 10: could not generate random cancel key |