Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:
> At Fri, 20 May 2022 11:02:21 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in
>> Doesn't the step s1_table_stats needs a blocking condition (s2_ff)?
> s/needs/need/;
> If I removed the step s2_ff, I see the same difference. So I think it
> is that. Some other permutations seem to need the same.
Hmm ... it does seem like the answer might be somewhere around there,
but it's not there exactly. This won't fix it:
- s1_table_stats
+ s1_table_stats(s2_ff)
That sort of marker only stabilizes cases where two different steps might
be reported as completing in either order. In this case, that's clearly
not the problem. What we do need is to ensure that s1_table_stats doesn't
*launch* before s2_ff is done. However, it doesn't look to me like that's
what's happening. isolation/README explains that
Notice that these markers can only delay reporting of the completion
of a step, not the launch of a step. The isolationtester will launch
the next step in a permutation as soon as (A) all prior steps of the
same session are done, and (B) the immediately preceding step in the
permutation is done or deemed blocked. For this purpose, "deemed
blocked" means that it has been seen to be waiting on a database lock,
or that it is complete but the report of its completion is delayed by
one of these markers.
There's no "waiting..." reports in the test output, nor do we have any
condition markers in stats.spec right now, so I don't think any steps
have been "deemed blocked".
What I am wondering about at this point is whether the effects of
pg_stat_force_next_flush() could somehow be delayed until after we
have told the client the command is complete. I've not poked into
the code in that area, but if that could happen it'd explain this
behavior.
regards, tom lane