Re: chained transactions

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: chained transactions
Date: 2019-01-02 15:02:21
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On 26/12/2018 09:20, Fabien COELHO wrote:
> I try to avoid global variables when possible as a principle, because I
> paid to learn that they are bad:-) Maybe I'd do a local struct, declare an
> instance within the function, and write two functions to dump/restore the
> transaction status variables into the referenced struct. Maybe this is not
> worth the effort.

Those are reasonable alternatives, I think, but it's a bit overkill in
this case.

>>> About the tests: I'd suggest to use more options on the different tests,
>>> eg SERIALIZABLE, READ ONLY… Also ISTM that tests should show
>>> transaction_read_only value as well.
>> OK, updated a bit. (Using READ ONLY doesn't work because then you can't
>> write anything inside the transaction.)
> Sure. Within a read-only tx, it could check that transaction_read_only is
> on, and still on when chained, though.

I think the tests prove the point that the values are set and unset and
reset in various scenarios. We don't need to test every single
combination, that's not the job of this patch.

> The documentation should probably tell in the compatibility sections that
> AND CHAIN is standard conforming.

Good point. Updated that.

> In the automatic rollback tests, maybe I'd insert 3 just once, and use
> another value for the chained transaction.


> Tests may eventually vary BEGIN/START, COMMIT/END, ROLLBACK/ABORT.

Those work on the parser level, so don't really affect this patch. It
would make the tests more confusing to read, I think.

> As you added a SAVEPOINT, maybe I'd try rollbacking to it.

That would error out and invalidate the subsequent tests, so it's not
easily possible. We could write a totally separate test for it, but I'm
not sure what that would be proving.

Updated patches attached.

Peter Eisentraut
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment Content-Type Size
v4-0001-Transaction-chaining.patch text/plain 22.9 KB
v4-0002-Transaction-chaining-support-in-PL-pgSQL.patch text/plain 14.8 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2019-01-02 15:07:40 Re: chained transactions
Previous Message Ron 2019-01-02 14:04:26 Re: Query planner / Analyse statistics bad estimate rows=1 with maximum statistics 10000 on PostgreSQL 10.2