From: Tom Lane <tgl@sss.pgh.pa.us>
To: Wells Oliver <wells.oliver@gmail.com>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: pgsql-admin <pgsql-admin@postgresql.org>
Subject: Re: Odd pg dump error: cache lookup failure
Date: Tue, 25 Aug 2020 19:24:04 -0400
Message-ID: <2775007.1598397844@sss.pgh.pa.us> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: tgl@sss.pgh.pa.us, wells.oliver@gmail.com, sfrost@snowman.net, alvherre@2ndquadrant.com
Subject: Re: Odd pg dump error: cache lookup failure
In-Reply-To: <2775007.1598397844@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox