Re: Odd pg dump error: cache lookup failure

From: Wells Oliver <wells(dot)oliver(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-admin <pgsql-admin(at)postgresql(dot)org>
Subject: Re: Odd pg dump error: cache lookup failure
Date: 2020-08-25 18:23:25
Message-ID: CAOC+FBXXq_iDU9iFHUoL5F8PY8pZawiLQ1xuPq3VW9_RJcN0JQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

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(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > * Alvaro Herrera (alvherre(at)2ndquadrant(dot)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
>

--
Wells Oliver
wells(dot)oliver(at)gmail(dot)com <wellsoliver(at)gmail(dot)com>

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Tom Lane 2020-08-25 19:05:27 Re: Odd pg dump error: cache lookup failure
Previous Message Tom Lane 2020-08-25 17:24:36 Re: Odd pg dump error: cache lookup failure