On Sun, Jun 13, 2021 at 06:09:20PM -0400, Tom Lane wrote: > Noah Misch <n...@leadboat.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.
