Re: BUG #17717: Regression in vacuumdb (15 is slower than 10/11 and possible memory issue)

Nathan Bossart <nathandbossart@gmail.com>

From: Nathan Bossart <nathandbossart@gmail.com>

To: Peter Geoghegan <pg@bowt.ie>

Cc: Tom Lane <tgl@sss.pgh.pa.us>, postgresql@taljaren.se, pgsql-bugs@lists.postgresql.org, Michael Paquier <michael@paquier.xyz>

Date: 2022-12-18T23:55:00Z

Lists: pgsql-bugs, pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Add options to control whether VACUUM runs vac_update_datfrozenxid.
- a46a7011b271 16.0 landed
Use catalog query to discover tables to process in vacuumdb
- e0c2933a767c 12.0 cited

On Thu, Dec 15, 2022 at 08:39:54PM -0800, Peter Geoghegan wrote:
> On Thu, Dec 15, 2022 at 1:57 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I could get behind manual VACUUM not invoking vac_update_datfrozenxid
>> by default, perhaps.  But if it can never call it, then that is a
>> fairly important bit of housekeeping that is unreachable except by
>> autovacuum.  No doubt the people who turn off autovacuum are benighted,
>> but they're still out there.
> 
> I wouldn't mind adding another option for this to VACUUM. We already
> have a couple of VACUUM options that are only really needed as escape
> hatches, or perhaps as testing tools used by individual Postgres
> hackers. Another one doesn't seem too bad. The VACUUM command should
> eventually become totally niche, so I'm not too concerned about going
> overboard here.

Perhaps there could also be an update-datfrozenxid function that vacuumdb
calls when finished with a database.  Even if vacuum becomes smarter about
calling vac_update_datfrozenxid, this might still be worth doing.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com