Re: Prepared transaction releasing locks before deregistering its GID

On Tue, Feb 19, 2019 at 08:17:14PM +0100, Oleksii Kliukin wrote:
> I gave it a spin on the same VM host as shown to constantly reproduce the
> issue and observed neither 'identifier already in use' nor any locking
> issues over a few dozens of runs, so it looks good to me.

Thanks for the confirmation. I'll try to wrap up this one then.

> That was HEAD, but since FinishPreparedTransaction seems to be identical
> there and on the back branches it should work for PG 10 and 11 as well.

The issue exists since two-phase commit has been added, down to 8.1 if
my read of the code is right, so it took 14 years to be found.
Congrats. I have also manually tested that the code is broken down to
9.4 though.

It is good that you stress-test 2PC the way you do, and that's the
second bug you have spotted since the duplicate XIDs in the standby
snapshots which are now lazily discarded at recovery. 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. In the event of a
back-patch, on top of the rest we would need to rework RemoveGXact so
as it does not take a LWLock on two-phase state data in 10 and
upwards, so that would be invasive, and we have way less automated
testing in those versions..
--
Michael