Each of the refreshes would definitely use CONCURRENTLY.
On Tue, Aug 25, 2020 at 12:51 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
I wrote: > Wells Oliver <wells.oliver@gmail.com> writes: >> And refreshing materialized views during the dump process wouldn't cause >> this?
> matviews can't be part of inheritance trees AFAIR, so we'd need some > other theory to explain it that way.
Oh wait a second. Matviews can have indexes, and getTables doesn't lock them (because we don't allow LOCK TABLE on views). So it's fairly clear that you could get here with no lock if 1152770777 is a matview. However, it's still not entirely clear how a refresh could trigger the observed error. We certainly aren't changing the matview's OID when we do that. Do we rewrite the pg_attribute entries anyway? And even if we do, why would there be a problem?