Re: BUG #17717: Regression in vacuumdb (15 is slower than 10/11 and possible memory issue)
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Peter Geoghegan <pg@bowt.ie>, postgresql@taljaren.se,
pgsql-hackers@lists.postgresql.org,
Michael Paquier <michael@paquier.xyz>
Date: 2022-12-28T22:05:39Z
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
Nathan Bossart <nathandbossart@gmail.com> writes: > On Wed, Dec 28, 2022 at 03:13:23PM -0500, Tom Lane wrote: >> + executeCommand(conn, "VACUUM (ONLY_DATABASE_STATS);", echo); > When I looked at this, I thought it would be better to send the command > through the parallel slot machinery so that failures would use the same > code path as the rest of the VACUUM commands. However, you also need to > adjust ParallelSlotsWaitCompletion() to mark the slots as idle so that the > slot array can be reused after it is called. Hm. I was just copying the way commands are issued further up in the same function. But I think you're right: once we've done ParallelSlotsAdoptConn(sa, conn); it's probably not entirely kosher to use the conn directly. regards, tom lane