From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Catalin Iacob <iacobcatalin(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [bug fix] Savepoint-related statements terminates connection |
Date: | 2017-09-08 00:49:00 |
Message-ID: | CANP8+jLYb17ObD0_UwSZU_RVH_QCPY3KkUaFdr5dML1CzYYV2Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 7 September 2017 at 11:31, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)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.
Always happy to use a good idea... (any better way to re-locate that
discussion?)
1. Allow SET to set multiple parameters...
SET guc1 = x, guc2 = y
This looks fairly straightforward
2. Allow SET to work only for a single command...
SET guc1 = x, guc2 = y FOR query
Don't see anything too bad about that...
Requires a new GUC mode for "statement local" rather than "transaction local"
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2017-09-08 00:52:48 | Re: pgbench: Skipping the creating primary keys after initialization |
Previous Message | Simon Riggs | 2017-09-08 00:36:00 | Re: [bug fix] Savepoint-related statements terminates connection |