Re: Experimenting with hash tables inside pg_dump - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Experimenting with hash tables inside pg_dump
Date
Msg-id 2652394.1634868802@sss.pgh.pa.us
Whole thread Raw
In response to Re: Experimenting with hash tables inside pg_dump  (Andres Freund <andres@anarazel.de>)
Responses Re: Experimenting with hash tables inside pg_dump  (Andres Freund <andres@anarazel.de>)
List 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



pgsql-hackers by date:

Previous
From: "shiy.fnst@fujitsu.com"
Date:
Subject: RE: Data is copied twice when specifying both child and parent table in publication
Next
From: Peter Geoghegan
Date:
Subject: MDAM techniques and Index Skip Scan patch