Re: [PATCH] pg_dump: lock tables in batches

Jacob Champion <jchampion@timescale.com>

From: Jacob Champion <jchampion@timescale.com>

To: Tom Lane <tgl@sss.pgh.pa.us>

Cc: Andres Freund <andres@anarazel.de>, Fabrízio de Royes Mello <fabriziomello@gmail.com>, Aleksander Alekseev <aleksander@timescale.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>

Date: 2022-12-07T23:13:43Z

Lists: 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 →

During pg_dump startup, acquire table locks in batches.
- 5f53b42cfd05 16.0 landed

On Wed, Dec 7, 2022 at 2:53 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Is "-s" mode actually a relevant criterion here?  With per-table COPY
> commands added into the mix you could not possibly get better than 2x
> improvement, and likely a good deal less.

Don't we hit this code path in pg_upgrade? You won't see huge
round-trip times, of course, but you also won't see COPY.

Absolute performance aside, isn't there another concern that, the
longer it takes for us to lock the tables, the bigger the window there
is for someone to interfere with them between our catalog query and
the lock itself?

--Jacob