Re: Decoupling antiwraparound autovacuum from special rules around auto cancellation

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Decoupling antiwraparound autovacuum from special rules around auto cancellation
Date: 2023-01-24 03:22:18
Message-ID: CAH2-Wzkm=AGL0H5BO_ESU5Q=QFR6mMA0dyXxnJErdBZdJb2FFw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jan 23, 2023 at 6:56 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> Why is there TABLE_ in AUTOVACUUM_TABLE_XID_AGE but not
> AUTOVACUUM_DEAD_TUPLES? Both are on tables.

Why does vacuum_freeze_table_age contain the word "table", while
autovacuum_vacuum_scale_factor does not?

To me, "table XID age" is a less awkward term for "relfrozenxid
advancing", useful in contexts where it's probably more important to
be understood by non-experts than it is to be unambiguous. Besides,
relfrozenxid works at the level of the pg_class metadata. Nothing
whatsoever needs to have changed about the table itself, nor will
anything necessarily be changed by VACUUM (except the relfrozenxid
field from pg_class).

> What do you think about naming this VacuumTriggerType and adding an
> VAC_TRIG_MANUAL or such?

But we're not doing anything with it in the context of manual VACUUMs.
I'd prefer to keep this about what autovacuum.c thought needed to
happen, at least for as long as manual VACUUMs are something that
autovacuum.c knows nothing about.

> > - bool force_vacuum;
> > + TransactionId relfrozenxid = classForm->relfrozenxid;
> > + MultiXactId relminmxid = classForm->relminmxid;
> > + AutoVacType trigger = AUTOVACUUM_NONE;
> > + bool tableagevac;
>
> Here + below we end up with three booleans that just represent the choices in
> our fancy new enum. That seems awkward to me.

I don't follow. It's true that "wraparound" is still a synonym of
"tableagevac" in 0001, but that changes in 0002. And even if you
assume that 0002 won't get in, I think that it still makes sense to
structure it in a way that shows that in principle the "wraparound"
behaviors don't necessarily have to be used whenever "tableagevac" is
in use.

> > @@ -3169,14 +3212,15 @@ autovacuum_do_vac_analyze(autovac_table *tab, BufferAccessStrategy bstrategy)
> > static void
> > autovac_report_activity(autovac_table *tab)

> Somehow the added "for ..." sounds a bit awkward. "autovacuum for table XID
> age". Maybe "autovacuum due to ..."?

That works just as well IMV. I'll change it to that.

Anything else for 0001? Would be nice to get it committed tomorrow.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2023-01-24 03:23:27 Test failures of 100_bugs.pl
Previous Message Kyotaro Horiguchi 2023-01-24 03:05:30 Re: Time delayed LR (WAS Re: logical replication restrictions)