And refreshing materialized views during the dump process wouldn't cause this?
On Tue, Aug 25, 2020 at 12:05 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Wells Oliver <wells.oliver@gmail.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.
