On Sun, Aug 08, 2021 at 12:00:55AM +0500, Andrey Borodin wrote:
> Changes:
> 1. Added assert in step 2 (fix for missed invalidation message). I wonder how deep possibly could be
RelationBuildDesc()inside RelationBuildDesc() inside RelationBuildDesc() ... ? If the depth is unlimited we, probably,
needa better data structure.
I don't know either, hence that quick data structure to delay the question.
debug_discard_caches=3 may help answer the question. RelationBuildDesc()
reads pg_constraint, which is !rd_isnailed. Hence, I expect one can at least
get RelationBuildDesc("pg_constraint") inside RelationBuildDesc("user_table").
> Tomorrow I'll try to cleanup step 1 (tap tests).
For the final commits, I would like to have two commits. The first will fix
the non-2PC bug and add the test for that fix. The second will fix the 2PC
bug and add the additional test. Feel free to structure your changes into
more patch files, so long as it's straightforward to squash them into two
commits that way.
A few things I noticed earlier:
> --- a/contrib/amcheck/Makefile
> +++ b/contrib/amcheck/Makefile
> @@ -12,7 +12,7 @@ PGFILEDESC = "amcheck - function for verifying relation integrity"
>
> REGRESS = check check_btree check_heap
>
> -TAP_TESTS = 1
> +TAP_TESTS = 2
TAP_TESTS is a Boolean flag, not a count. Leave it set to 1.
> --- /dev/null
> +++ b/contrib/amcheck/t/002_cic_2pc.pl
> +$node->append_conf('postgresql.conf', 'lock_timeout = 5000');
> +my $main_timer = IPC::Run::timeout(5);
> +my $reindex_timer = IPC::Run::timeout(5);
Values this short cause spurious buildfarm failures. Generally, use 180s for
timeouts that do not expire in a successful run.
> +# Run background pgbench with CIC. We cannot mix-in this script into single pgbench:
> +# CIC will deadlock with itself occasionally.
Consider fixing that by taking an advisory lock before running CIC. However,
if use of separate pgbench executions works better, feel free to keep that.
> +pgbench(
> + '--no-vacuum --client=5 --time=1',
Consider using a transaction count instead of --time. That way, slow machines
still catch the bug, and fast machines waste less time. For the "concurrent
OID generation" test, I tuned the transaction count so the test failed about
half the time[1] on a buggy build.
> + \set txid random(1, 1000000000)
> + BEGIN;
> + INSERT INTO tbl VALUES(0);
> + PREPARE TRANSACTION 'tx:txid';
Try "PREPARE TRANSACTION 'c:client_id'" (or c:client_id:txid) to eliminate the
chance of collision.
[1] https://postgr.es/m/20160215171129.GA347322@tornado.leadboat.com
