On Tue, Oct 13, 2020 at 9:11 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Tue, Oct 13, 2020 at 9:02 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > On Tue, Oct 13, 2020 at 4:54 AM Masahiko Sawada > > <masahiko.saw...@2ndquadrant.com> wrote: > > > > > > Attached the updated version patch. Please review it. > > > > > > > I have pushed this but it failed in one of the BF. See > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=florican&dt=2020-10-13%2003%3A07%3A25 > > > > The failure is shown below and I am analyzing it. See, if you can > > provide any insights. > > > > @@ -58,7 +58,7 @@ > > SELECT name, spill_txns, spill_count FROM pg_stat_replication_slots; > > name | spill_txns | spill_count > > -----------------+------------+------------- > > - regression_slot | 1 | 12 > > + regression_slot | 1 | 10 > > (1 row) > > > > -- reset the slot stats, and wait for stats collector to reset > > @@ -96,7 +96,7 @@ > > SELECT name, spill_txns, spill_count FROM pg_stat_replication_slots; > > name | spill_txns | spill_count > > -----------------+------------+------------- > > - regression_slot | 1 | 12 > > + regression_slot | 1 | 10 > > (1 row) > > > > The reason for this problem could be that there is some transaction > (say by autovacuum) which happened interleaved with this transaction > and committed before this one. Now during DecodeCommit of this > background transaction, we will send the stats accumulated by that > time which could lead to such a problem. >
If this theory is correct then I think we can't rely on the 'spill_count' value, what do you think? -- With Regards, Amit Kapila.
