Re: Resetting spilled txn statistics in pg_stat_replication - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Resetting spilled txn statistics in pg_stat_replication
Date
Msg-id 3414603.1602567355@sss.pgh.pa.us
Whole thread Raw
In response to Re: Resetting spilled txn statistics in pg_stat_replication  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Resetting spilled txn statistics in pg_stat_replication  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
Amit Kapila <amit.kapila16@gmail.com> writes:
>> It is possible that MAXALIGN stuff is playing a role here and or the
>> background transaction stuff. I think if we go with the idea of
>> testing spill_txns and spill_count being positive then the results
>> will be stable. I'll write a patch for that.

Here's our first failure on a MAXALIGN-8 machine:

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=grison&dt=2020-10-13%2005%3A00%3A08

So this is just plain not stable.  It is odd though.  I can
easily think of mechanisms that would cause the WAL volume
to occasionally be *more* than the "typical" case.  What
would cause it to be *less*, if MAXALIGN is ruled out?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Resetting spilled txn statistics in pg_stat_replication
Next
From: Amit Kapila
Date:
Subject: Re: Resetting spilled txn statistics in pg_stat_replication