| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Resetting spilled txn statistics in pg_stat_replication |
| Date: | 2020-10-13 05:35:55 |
| Message-ID: | 3414603.1602567355@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Amit Kapila <amit(dot)kapila16(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2020-10-13 05:54:07 | Re: Resetting spilled txn statistics in pg_stat_replication |
| Previous Message | Amit Kapila | 2020-10-13 05:29:00 | Re: Resetting spilled txn statistics in pg_stat_replication |