| From: | Stephen Frost <sfrost(at)snowman(dot)net> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Wells Oliver <wells(dot)oliver(at)gmail(dot)com>, pgsql-admin <pgsql-admin(at)postgresql(dot)org> |
| Subject: | Re: Odd pg dump error: cache lookup failure |
| Date: | 2020-08-24 23:16:21 |
| Message-ID: | 20200824231621.GA29590@tamriel.snowman.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
Greetings,
* Alvaro Herrera (alvherre(at)2ndquadrant(dot)com) wrote:
> On 2020-Aug-24, Wells Oliver wrote:
> > 12.4. Both of those queries return no rows, with and without those options
> > set.
> >
> > We do do some nightly processing of data during the same window, in which
> > views are re-materialized: would that cause this issue? No non-temporary
> > tables are dropped or re-created, though.
>
> Oh, so this could be some kind of relation that exists when pg_dump
> starts but is dropped before it reaches the point where it dumps the
> data for that relation.
>
> Hmm.
That'd be cute since pg_dump should be locking all the relations that
it's going to export the data from...
Thanks,
Stephen
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Kellerer | 2020-08-25 05:32:09 | How to debug logical replication error "columns are missing" if they are not |
| Previous Message | Alvaro Herrera | 2020-08-24 23:13:38 | Re: Odd pg dump error: cache lookup failure |