From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Wells Oliver <wells.oliver@gmail.com>
Cc: pgsql-admin <pgsql-admin@postgresql.org>
Subject: Re: Odd pg dump error: cache lookup failure
Date: Tue, 25 Aug 2020 13:24:36 -0400
Message-ID: <2748788.1598376276@sss.pgh.pa.us> (raw)
In-Reply-To: <20200824231621.GA29590@tamriel.snowman.net>
References: <CAOC+FBXosgRbSi-A+VLP8t5pmErEnP3M8aRJJ1z5HcyhvQM_eA@mail.gmail.com>
<20200824231338.GA30623@alvherre.pgsql>
<20200824231621.GA29590@tamriel.snowman.net>
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
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: tgl@sss.pgh.pa.us, sfrost@snowman.net, alvherre@2ndquadrant.com, wells.oliver@gmail.com
Subject: Re: Odd pg dump error: cache lookup failure
In-Reply-To: <2748788.1598376276@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox