Re: Prepared transaction releasing locks before deregistering its GID - Mailing list pgsql-hackers

From Oleksii Kliukin
Subject Re: Prepared transaction releasing locks before deregistering its GID
Date
Msg-id 1FBAA9D7-ACB1-4FD1-B285-A40D3FC056B6@hintbits.com
Whole thread Raw
In response to Re: Prepared transaction releasing locks before deregistering its GID  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Prepared transaction releasing locks before deregistering its GID  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Michael Paquier <michael@paquier.xyz> wrote:

>
> Attached is an updated patch.  Thanks for the feedback.

@@ -1755,7 +1755,7 @@ void
 multixact_twophase_recover(TransactionId xid, uint16 info,
                           void *recdata, uint32 len)
 {
-   BackendId   dummyBackendId = TwoPhaseGetDummyBackendId(xid);
+   BackendId   dummyBackendId = TwoPhaseGetDummyBackendId(xid, true);
    MultiXactId oldestMember;

RecoverPreparedTransactions calls ProcessRecords with
twophase_recover_callbacks right after releasing the TwoPhaseStateLock, so I
think lock_held should be false here (matching the similar call of
TwoPhaseGetDummyProc at lock_twophase_recover).

Since the patch touches TwoPhaseGetDummyBackendId, let’s fix the comment
header to mention it instead of TwoPhaseGetDummyProc

> Now, it seems
> to me that the potential ABI breakage argument (which can be solved by
> introducing an extra routine, which means more conflicts to handle
> when back-patching 2PC stuff), and the time it took to find the issue
> are pointing out that we should patch only HEAD.

Sounds reasonable.

Regards,
Oleksii Kliukin



pgsql-hackers by date:

Previous
From: "Matsumura, Ryo"
Date:
Subject: RE: SQL statement PREPARE does not work in ECPG
Next
From: Peter Eisentraut
Date:
Subject: Re: restrict pg_stat_ssl to superuser?