Horton

Re: [bug fix] Savepoint-related statements terminates connection

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Catalin Iacob <iacobcatalin@gmail.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-07T18:31:37Z
Lists: pgsql-hackers 
Simon Riggs <simon@2ndquadrant.com> writes:
> I would like to relax the restriction to allow this specific use case...
>   SET work_mem = X; SET max_parallel_workers = 4; SELECT ...
> so we still have only one command (the last select), yet we have
> multiple GUC settings beforehand.

On what basis do you claim that's only one command?  It would return
multiple CommandCompletes, for starters, so that it breaks the protocol
just as effectively as any other loosening.

Moreover, I imagine the semantics you really want is that the SETs only
apply for the duration of the command.  This wouldn't provide that
result either.

Haas' idea of some kind of syntactic extension, like "LET guc1 = x,
guc2 = y FOR statement" seems more feasible to me.  I'm not necessarily
wedded to that particular syntax, but I think it has to look like
a single-statement construct of some kind.

			regards, tom lane

Commits

  1. Improve documentation about behavior of multi-statement Query messages.

  2. Fix handling of savepoint commands within multi-statement Query strings.

  3. Arrange for PreventTransactionChain to reject commands submitted as part