Hi, On 2022-05-20 00:22:14 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > Hm. Does the instability vanish if you switch s2_commit_prepared_a and > > s1_ff? > > Like this?
Yea. > diff --git a/src/test/isolation/specs/stats.spec > b/src/test/isolation/specs/stats.spec > index be4ae1f4ff..70be29b207 100644 > --- a/src/test/isolation/specs/stats.spec > +++ b/src/test/isolation/specs/stats.spec > @@ -562,8 +562,9 @@ permutation > s1_table_insert_k1 # should be counted > s1_table_update_k1 # dito > s1_prepare_a > + s1_ff > s2_commit_prepared_a > - s1_ff s2_ff > + s2_ff > s1_table_stats > > # S1 prepares, S1 aborts prepared > > There's some fallout in the expected-file, of course, but this > does seem to fix it (20 consecutive successful runs now at > 100/2). Don't see why though ... I think what might be happening is that the transactional stats updates get reported by s2 *before* the non-transactional stats updates come in from s1. I.e. the pgstat_report_stat() at the end of s2_commit_prepared_a does a report, because the machine is slow enough for it to be "time to reports stats again". Then s1 reports its non-transactional stats. It looks like our stats maintenance around truncation isn't quite "concurrency safe". That code hasn't meaningfully changed, but it'd not be surprising if it's not 100% precise... Greetings, Andres Freund
