| 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:51:03 |
| Message-ID: | 2762819.1598385063@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
I wrote:
> Wells Oliver <wells(dot)oliver(at)gmail(dot)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?
Are your refreshes using CONCURRENTLY?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Wells Oliver | 2020-08-25 19:53:14 | Re: Odd pg dump error: cache lookup failure |
| Previous Message | Wells Oliver | 2020-08-25 19:44:50 | Re: Odd pg dump error: cache lookup failure |