Re: Odd pg dump error: cache lookup failure

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Wells Oliver <wells(dot)oliver(at)gmail(dot)com>
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 19:05:27
Message-ID: 2760667.1598382327@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Wells Oliver <wells(dot)oliver(at)gmail(dot)com> writes:
> 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.

I overlooked something in my previous quick code scan, which is that
flagInhTables() will set the "interesting" flag on parents of tables
that are due to be dumped, even if the parents are not. This *will*
result in running getIndexes on tables that we have no lock on.

However, it's not quite clear how that leads to the observed failure,
because if we have a lock on some child partition, it shouldn't really
be possible for someone to drop an index on the partition root,
should it? In any case you didn't admit to doing such things.
This theory would require both that a table-to-be-dumped is a
partition of some partitioned table that's in an excluded schema,
and that you're concurrently doing DDL on that partitioned table.

regards, tom lane

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Wells Oliver 2020-08-25 19:06:23 Re: Odd pg dump error: cache lookup failure
Previous Message Wells Oliver 2020-08-25 18:23:25 Re: Odd pg dump error: cache lookup failure