Re: Continuing instability in insert-conflict-specconflict test

On Sun, Jun 13, 2021 at 06:09:20PM -0400, Tom Lane wrote:
> Noah Misch <noah(at)leadboat(dot)com> writes:
> > On Sun, Jun 13, 2021 at 04:48:48PM -0400, Tom Lane wrote:
> >> * Adjust the test script's functions to emit a NOTICE *after* acquiring
> >> a lock, not before.
>
> > I suspect that particular lock acquisition merely unblocks the processing that
> > reaches the final lock state expected by the test. So, ...
>
> Ah, you're probably right.
>
> >> * Annotate permutations with something along the lines of "expect N
> >> NOTICE outputs before allowing this step to be considered complete",
> >> which we'd attach to the unlock steps.
>
> > ... I don't expect this to solve $SUBJECT. It could be a separately-useful
> > feature, though.
>
> I think it would solve it. In the examples at hand, where we have
>
> @@ -377,8 +377,6 @@
> pg_advisory_unlock
>
> t
> -s1: NOTICE: blurt_and_lock_123() called for k1 in session 1
> -s1: NOTICE: acquiring advisory lock on 2
> step s2_upsert: <... completed>
> step controller_print_speculative_locks:
> SELECT pa.application_name, locktype, mode, granted

It would solve that one particular diff. I meant that it wouldn't solve the
aforementioned pg_locks diffs:

dory │ 2020-03-14 19:35:31 │ HEAD │ http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dory&dt=2020-03-14%2019%3A35%3A31
walleye │ 2021-03-25 05:00:44 │ REL_13_STABLE │ http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=walleye&dt=2021-03-25%2005%3A00%3A44
walleye │ 2021-05-05 17:00:41 │ REL_13_STABLE │ http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=walleye&dt=2021-05-05%2017%3A00%3A41

> We might be able to get rid of the stuff about concurrent step
> completion in isolationtester.c if we required the spec files
> to use annotations to force a deterministic step completion
> order in all such cases.

Yeah. If we're willing to task spec authors with that, the test program can't
then guess wrong under unusual timing.