Interesting: the only parameters I pass are a list of excluded schemas via -N arguments, as well as a --format=c.
I don't think anything in the excluded schemas is being referenced by something that is set to be dumped: is that what you're thinking? It's possible, and I'll dig a bit, but things are generally walled off pretty well.
On Tue, Aug 25, 2020 at 10:24 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Stephen Frost <sfrost@snowman.net> writes: > * Alvaro Herrera (alvherre@2ndquadrant.com) wrote: >> Oh, so this could be some kind of relation that exists when pg_dump >> starts but is dropped before it reaches the point where it dumps the >> data for that relation.
> That'd be cute since pg_dump should be locking all the relations that > it's going to export the data from...
The failure is evidently in getIndexes's query, and that will try to acquire information about every table not satisfying
if (!tbinfo->hasindex) continue; if (!(tbinfo->dobj.dump & DUMP_COMPONENT_DEFINITION) && !tbinfo->interesting) continue;
However, getTables previously acquired locks on only the tables satisfying
(BTW, Stephen, the first line of that is clearly redundant now...)
AFAICS the tbinfo->interesting test is equivalent to dobj.dump being nonzero. Also, while the relkind restriction looks problematic, I don't think hasindex could be true for any rels of other relkinds. So the explanation has to lie in the fact that the former is an OR condition, ie probe table if "DUMP_COMPONENT_DEFINITION" *or* "interesting", while the latter is an AND condition, ie lock table if "dump" *and* "DUMP_COMPONENTS_REQUIRING_LOCK".
This'd be irrelevant if pg_dump is just dumping everything, which leads me to ask what are pg_dump's command line switches, and is it possible that the switches are excluding partitioning or inheritance parents of tables that are due to be dumped?
