Hi,
On 2022-05-20 00:22:14 -0400, Tom Lane wrote:
> Andres Freund <andres@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