Re: confusion about this commit "Revert "Skip redundant anti-wraparound vacuums""

actually out test instance include 2aa6e331ead7f3ad080561495ad4bd3bc7cd8913 this commit, not yet reverted this commit.

| |
jiye
|
|
jiye_sw(at)126(dot)com
|
---- Replied Message ----
| From | Julien Rouhaud<rjuju123(at)gmail(dot)com> |
| Date | 6/7/2023 14:00 |
| To | Robert Haas<robertmhaas(at)gmail(dot)com> |
| Cc | jiye<jiye_sw(at)126(dot)com> ,
tgl(at)sss(dot)pgh(dot)pa(dot)us<tgl(at)sss(dot)pgh(dot)pa(dot)us> ,
pgsql-hackers(at)lists(dot)postgresql(dot)org<pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject | Re: confusion about this commit "Revert "Skip redundant anti-wraparound vacuums"" |
On Tue, Jun 06, 2023 at 03:30:02PM -0400, Robert Haas wrote:
On Mon, Jun 5, 2023 at 1:50 AM jiye <jiye_sw(at)126(dot)com> wrote:

we can not get determinate test case as this issue reproduce only once,
and currently autovaccum can works as we using vacuum freeze for each
tables of each database.

our client's application is real online bank business, and have serveral
customer database, do a majority of update opertaion as result trigger
some table dead_tup_ratio nealy 100%, but can not find any autovacuum
process work for a very long time before we do vacuum freeze manally.

I tend to doubt that this is caused by the commit you're blaming, because
that commit purports to skip autovacuum operations only if some other
vacuum has already done the work. Here you are saying that you see no
autovacuum tasks at all.

I'm a bit confused about what commit is actually being discussed here.

Is it commit 2aa6e331ead7f3ad080561495ad4bd3bc7cd8913? FTR this commit was
indeed problematic and eventually reverted in 12.3
(3ec8576a02b2b06aa214c8f3c2c3303c8a67639f), as it was leading to exactly the
problem described here (autovacuum kept triggering the same jobs that were
silently ignored, leading to absolutely no visible activity from a user point
of view).