From: Tom Lane <tgl@sss.pgh.pa.us>
To: Wells Oliver <wells.oliver@gmail.com>
cc: Stephen Frost <sfrost@snowman.net>,
        Alvaro Herrera <alvherre@2ndquadrant.com>,
        pgsql-admin <pgsql-admin@postgresql.org>
Subject: Re: Odd pg dump error: cache lookup failure
In-reply-to: <2763002.1598385281@sss.pgh.pa.us>
References: 
 <CAOC+FBXosgRbSi-A+VLP8t5pmErEnP3M8aRJJ1z5HcyhvQM_eA@mail.gmail.com>
 <20200824231338.GA30623@alvherre.pgsql>
 <20200824231621.GA29590@tamriel.snowman.net>
 <2748788.1598376276@sss.pgh.pa.us>
 <CAOC+FBXXq_iDU9iFHUoL5F8PY8pZawiLQ1xuPq3VW9_RJcN0JQ@mail.gmail.com>
 <2760667.1598382327@sss.pgh.pa.us>
 <CAOC+FBVmcNR5d09YdNc_NG=b5_Y7OQmqbznJcGAt37U3wJxwpQ@mail.gmail.com>
 <2762015.1598384009@sss.pgh.pa.us>
 <CAOC+FBXLBO+r=9xF2c5E5vT7jGsqFq49LJ+Ka4Cqn16J38SLYQ@mail.gmail.com>
 <2763002.1598385281@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Tue, 25 Aug 2020 15:54:41 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2775006.1598397844.1@sss.pgh.pa.us>
Date: Tue, 25 Aug 2020 19:24:04 -0400
Message-ID: <2775007.1598397844@sss.pgh.pa.us>
Precedence: bulk

I wrote:
> Wells Oliver <wells.oliver@gmail.com> writes:
>> It doesn't exist any longer, which lead me to try to think of things that
>> might be dropped during the dump process.

> Hm, if you're actually *dropping* matviews during the dump then it's
> not so hard to explain this error.  They'd have to be ones that were
> selected to be dumped though.

I experimented a bit to try to reproduce this problem.  I cannot get
any sort of error from REFRESH (with or without CONCURRENTLY) in
parallel with a pg_dump.  If I drop a view or matview, I can easily
get an error, but I've not managed to reproduce one that looks like
yours; it tends to be more like

pg_dump: error: query failed: ERROR:  could not open relation with OID 45698

What I found that *would* reproduce "cache lookup failed for attribute"
from pg_get_indexdef() is to explicitly drop a matview's index just
before pg_dump gets to it.  So I wonder if you are doing that in your
"refresh" procedure.  The timing is not terribly tight; the drop has to
happen between where pg_dump acquires its transaction snapshot and where
it tries to investigate the matview's indexes, which could be some while
in a database with many objects.  Also, if the transaction doing the index
drop also takes out any exclusive locks on regular tables, that could make
it much easier to send pg_dump down this rabbit hole, since it'd block
on those locks till the damage was done.

			regards, tom lane