[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-admin
Subject:    Re: Odd pg dump error: cache lookup failure
From:       Wells Oliver <wells.oliver () gmail ! com>
Date:       2020-08-26 17:51:59
Message-ID: CAOC+FBVut6NY5y49s+SUWW-bNTCiLRhOkatxRLrnBd-BQJcPgw () mail ! gmail ! com
[Download RAW message or body]

Thanks Tom, this is intriguing. I've changed our backups to do pg_dump with
verbose, and if I see this issue again I'll dig a bit with the additional
information.

On Tue, Aug 25, 2020 at 4:24 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> 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
>


-- 
Wells Oliver
wells.oliver@gmail.com <wellsoliver@gmail.com>

[Attachment #3 (text/html)]

<div dir="ltr">Thanks Tom, this is intriguing. I&#39;ve changed our backups to do \
pg_dump with verbose, and if I see this issue again I&#39;ll dig a bit with the \
additional information.</div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Tue, Aug 25, 2020 at 4:24 PM Tom Lane &lt;<a \
href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>&gt; wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">I wrote:<br> &gt; Wells Oliver &lt;<a \
href="mailto:wells.oliver@gmail.com" target="_blank">wells.oliver@gmail.com</a>&gt; \
writes:<br> &gt;&gt; It doesn&#39;t exist any longer, which lead me to try to think \
of things that<br> &gt;&gt; might be dropped during the dump process.<br>
<br>
&gt; Hm, if you&#39;re actually *dropping* matviews during the dump then it&#39;s<br>
&gt; not so hard to explain this error.   They&#39;d have to be ones that were<br>
&gt; selected to be dumped though.<br>
<br>
I experimented a bit to try to reproduce this problem.   I cannot get<br>
any sort of error from REFRESH (with or without CONCURRENTLY) in<br>
parallel with a pg_dump.   If I drop a view or matview, I can easily<br>
get an error, but I&#39;ve not managed to reproduce one that looks like<br>
yours; it tends to be more like<br>
<br>
pg_dump: error: query failed: ERROR:   could not open relation with OID 45698<br>
<br>
What I found that *would* reproduce &quot;cache lookup failed for attribute&quot;<br>
from pg_get_indexdef() is to explicitly drop a matview&#39;s index just<br>
before pg_dump gets to it.   So I wonder if you are doing that in your<br>
&quot;refresh&quot; procedure.   The timing is not terribly tight; the drop has \
to<br> happen between where pg_dump acquires its transaction snapshot and where<br>
it tries to investigate the matview&#39;s indexes, which could be some while<br>
in a database with many objects.   Also, if the transaction doing the index<br>
drop also takes out any exclusive locks on regular tables, that could make<br>
it much easier to send pg_dump down this rabbit hole, since it&#39;d block<br>
on those locks till the damage was done.<br>
<br>
                                    regards, tom lane<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" \
class="gmail_signature"><div dir="ltr"><div>Wells Oliver<br><a \
href="mailto:wellsoliver@gmail.com" \
target="_blank">wells.oliver@gmail.com</a></div></div></div>



[prev in list] [next in list] [prev in thread] [next in thread]