Re: chained transactions

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: chained transactions
Date: 2019-03-18 20:20:39
Message-ID: alpine.DEB.2.21.1903181919410.27990@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hallo Peter,

> Updated patch. I have squashed the two previously separate patches
> together in this one.

Ok.

>> I do not understand the value of the SAVEPOINT in the tests.
>
> The purpose of the SAVEPOINT in the test is because it exercises
> different switch cases in CommitTransactionCommand() and
> AbortCurrentTransaction(). It's not entirely comprehensible from the
> outside, but code coverage analysis confirms it.

Ok.

>> Otherwise I'm okay with this patch.
>>
>> About the second patch, I'm still unhappy with functions named commit &
>> rollback doing something else, which result in somehow strange code, where
>> you have to guess that the transaction is restarted in all cases, either
>> within the commit function or explicitely.
>
> I have updated the SPI interface with your suggestions. I agree it's
> better that way.

Patch applies cleanly, compiles, make check ok, doc build ok.

Minor remarks:

In "xact.c", maybe I'd assign blockState in the else branch, instead of
overriding it?

About the static _SPI_{commit,rollback} functions: I'm fine with these
functions, but I'm not sure about their name. Maybe
_SPI_chainable_{commit,rollback} would be is clearer about their content?

Doc looks clear to me. ISTM "chain" should be added as an index term?

Tests look ok. Maybe I'd have series with mixed commit & rollback, instead
of only commit & only rollback?

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-03-18 20:23:03 Re: jsonpath
Previous Message Andres Freund 2019-03-18 20:16:47 Re: outdated reference to tuple header OIDs