Re: Assorted improvements in pg_dump

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>

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

Cc: Hans Buschmann <buschmann@nidsa.net>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>

Date: 2021-10-25T21:35:50Z

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 →

pg_dump: avoid unsafe function calls in getPolicies().
- b7333e826955 11.19 landed
- a5b26aaafe4f 13.10 landed
- 1ed6f1b9116c 12.14 landed
- 03ac48549438 14.7 landed
- 3e6e86abca01 15.0 landed
Postpone calls of unsafe server-side functions in pg_dump.
- e46e986baef0 13.10 landed
- b1f106420b1a 11.19 landed
- 55f30e6c7640 14.7 landed
- 344b7849200f 12.14 landed
- e3fcbbd623b9 15.0 landed
Account for TOAST data while scheduling parallel dumps.
- 65aaed22a849 15.0 landed
Use PREPARE/EXECUTE for repetitive per-object queries in pg_dump.
- be85727a3df7 15.0 landed
Avoid per-object queries in performance-critical paths in pg_dump.
- 9895961529ef 15.0 landed
Rethink pg_dump's handling of object ACLs.
- 0c9d84427f44 15.0 landed
Refactor pg_dump's tracking of object components to be dumped.
- 5209c0ba0bfd 15.0 landed
pg_dump: fix mis-dumping of non-global default privileges.
- 2acc84c6fd29 15.0 cited

Hi,

On 2021-10-25 16:02:34 -0400, Tom Lane wrote:
> So I'd like a better idea, but I'm not sure that that one is better.

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.

Greetings,

Andres Freund