Each of the refreshes would definitely use CONCURRENTLY.
On Tue, Aug 25, 2020 at 12:51 PM Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
I wrote:
> Wells Oliver <wells.oliver@xxxxxxxxx> 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?
Are your refreshes using CONCURRENTLY?
regards, tom lane
Wells Oliver
wells.oliver@xxxxxxxxx
wells.oliver@xxxxxxxxx
