Re: Experimenting with hash tables inside pg_dump
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2021-10-22T02:13:22Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes: > I wonder though if for some of them we should instead replace the per-object > queries with one query returning the information for all objects of a type. It > doesn't make all that much sense that we build and send one query for each > table and index. The trick is the problem I alluded to in another thread: it's not safe to do stuff like pg_get_expr() on tables we don't have lock on. I've thought about doing something like SELECT unsafe-functions FROM pg_class WHERE oid IN (someoid, someoid, ...) but in cases with tens of thousands of tables, it seems unlikely that that's going to behave all that nicely. The *real* fix, I suppose, would be to fix all those catalog-inspection functions so that they operate with respect to the query's snapshot. But that's not a job I'm volunteering for. Besides which, pg_dump still has to cope with back-rev servers where it wouldn't be safe. regards, tom lane
Commits
-
In pg_dump, use simplehash.h to look up dumpable objects by OID.
- 92316a4582a5 15.0 landed
-
Fix frontend version of sh_error() in simplehash.h.
- 974aedcea46d 15.0 landed
- 8cee4be6dc93 14.1 landed
- 2e01d050d989 13.5 landed