Stephen Frost <sfrost@xxxxxxxxxxx> writes:
> * Alvaro Herrera (alvherre@xxxxxxxxxxxxxxx) 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
if (tblinfo[i].dobj.dump &&
(tblinfo[i].relkind == RELKIND_RELATION ||
tblinfo->relkind == RELKIND_PARTITIONED_TABLE) &&
(tblinfo[i].dobj.dump & DUMP_COMPONENTS_REQUIRING_LOCK))
(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?
regards, tom lane
