From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Experimenting with hash tables inside pg_dump |
Date: | 2021-10-22 02:13:22 |
Message-ID: | 2652394.1634868802@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2021-10-22 02:16:00 | MDAM techniques and Index Skip Scan patch |
Previous Message | shiy.fnst@fujitsu.com | 2021-10-22 02:01:24 | RE: Data is copied twice when specifying both child and parent table in publication |