Re: Odd pg dump error: cache lookup failure

And refreshing materialized views during the dump process wouldn't cause
this?

On Tue, Aug 25, 2020 at 12:05 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> 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
>

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