Re: chained transactions - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: chained transactions
Date
Msg-id b989871c-b2d9-42b9-4461-ace590d1a7c0@iki.fi
Whole thread Raw
In response to chained transactions  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: chained transactions  (Michael Paquier <michael@paquier.xyz>)
List 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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: PG 10: could not generate random cancel key
Next
From: Alvaro Herrera
Date:
Subject: Re: PG 10: could not generate random cancel key