Re: [bug fix] Savepoint-related statements terminates connection
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Simon Riggs <simon@2ndquadrant.com>,
Michael Paquier <michael.paquier@gmail.com>,
"Tsunakawa,
Takayuki" <tsunakawa.takay@jp.fujitsu.com>,
Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-09-03T22:20:17Z
Lists: pgsql-hackers
Attachments
- introduce-implicit-transaction-blocks-2.patch (text/x-diff) patch
I wrote: > ... PFA a patch > that invents a notion of an "implicit" transaction block. On further consideration, I think the control logic I added in exec_simple_query() is a shade bogus. I set it up to only force an implicit transaction block when there are at least two statements remaining to execute. However, that has the result of allowing, eg, begin\; select 1\; commit\; vacuum; Now in principle it's perfectly OK to allow that, since the vacuum is alone in its transaction. But it feels more like an implementation artifact than a good design. The existing code doesn't allow it, and we might have a hard time duplicating this behavior if we ever significantly rewrote the transaction infrastructure. Plus I'd hate to have to explain it to users. I think we'd be better off enforcing transaction block restrictions on every statement in a multi-command string, regardless of the location of any COMMIT/ROLLBACK within the string. Hence, attached a v2 that does it like that. I also fully reverted 4f896dac1 by undoing its changes to PreventTransactionChain; other than that, the changes in xact.c are the same as before. regards, tom lane
Commits
-
Improve documentation about behavior of multi-statement Query messages.
- b976499480bd 11.0 landed
-
Fix handling of savepoint commands within multi-statement Query strings.
- 6eb52da3948d 11.0 landed
-
Arrange for PreventTransactionChain to reject commands submitted as part
- 4f896dac17f7 8.3.0 cited