From: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SET TRANSACTION in PL/pgSQL |
Date: | 2018-03-15 21:49:42 |
Message-ID: | CAPpHfdvuFeTMZOo4PQ0P55dWaYdHkh-Me4-1JeLcP=JF26UdYw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi!
On Wed, Feb 28, 2018 at 11:45 PM, Peter Eisentraut <
peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> Currently, you can't run SET TRANSACTION in PL/pgSQL. A normal SQL
> command run inside PL/pgSQL acquires a snapshot, but SET
> TRANSACTION does not work anymore if a snapshot is set. Here is a patch
> to work around that by handling this command separately. I have coded
> this here bypassing SPI entirely. But there is some overlap with the
> no_snapshot option in the patch "PL/pgSQL nested CALL with
> transactions", so maybe a better solution will arise. This will also
> inform how to tackle this in other PLs.
I didn't dig deeply into this subject. But should we rather teach SPI to
execute
utility statements without taking snapshot when not necessary. That seems
like what executor do for client provided queries. And that seems a bit
unlogical
that SPI behaves differently.
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2018-03-15 22:26:17 | Re: [HACKERS] GSoC 2017: weekly progress reports (week 6) |
Previous Message | Robert Haas | 2018-03-15 21:49:40 | Re: [HACKERS] Partition-wise aggregation/grouping |