Re: Assorted improvements in pg_dump

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

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Hans Buschmann <buschmann@nidsa.net>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2021-10-26T22:31:05Z
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 →
  1. pg_dump: avoid unsafe function calls in getPolicies().

  2. Postpone calls of unsafe server-side functions in pg_dump.

  3. Account for TOAST data while scheduling parallel dumps.

  4. Use PREPARE/EXECUTE for repetitive per-object queries in pg_dump.

  5. Avoid per-object queries in performance-critical paths in pg_dump.

  6. Rethink pg_dump's handling of object ACLs.

  7. Refactor pg_dump's tracking of object components to be dumped.

  8. pg_dump: fix mis-dumping of non-global default privileges.

Attachments

Andres Freund <andres@anarazel.de> writes:
> I guess we could move the prepared-statement handling into a query execution
> helper. That could then use a hashtable or something similar to check if a
> certain prepared statement already exists. That'd then centrally be extensible
> to deal with multiple connects etc.

That seems like more mechanism than is warranted.  I tried it with a
simple array of booleans, and that seems like not too much of a mess;
see revised 0006 attached.

(0001-0005 are the same as before; including them just to satisfy
the cfbot.)

			regards, tom lane