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 →
  1. Add options to control whether VACUUM runs vac_update_datfrozenxid.

  2. Use catalog query to discover tables to process in vacuumdb

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