Re: Prepared transaction releasing locks before deregistering its GID

On Sat, Feb 23, 2019 at 08:44:43AM +0900, Michael Paquier wrote:
> Thanks. I am still looking at this patch an extra time, so this may
> take at most a couple of days from my side. For now I have committed
> the test portion, which is independently useful and caused recovery of
> multixact post-commit callbacks to never be stressed.

Done. I have spent some time today looking at the performance of the
patch, designing a worst-case scenario to see how much bloat this adds
in COMMIT PREPARED by running across many sessions 2PC transactions
taking SHARE locks across many tables, as done in the script attached.

This test case runs across multiple sessions:
BEGIN;
SELECT lock_tables($NUM_TABLES);
PREPARE TRANSACTION 't_$i';
COMMIT PREPARED 't_$i';

lock_tables() is able to take a lock on a set of tables, bloating the
number of locks registered in the 2PC transaction, still those do not
conflict, so it gives an idea of the extra impact of holding
TwoPhaseStateLock longer. The script also includes a function to
create thousands of tables easily, and can be controlled with a couple
of parameters:
- number of tables to use, which will be locked.
- number of sessions.
- run time of pgbench.
--
Michael