Re: BUG #16812: Logical decoding error

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: mayur555b(at)protonmail(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #16812: Logical decoding error
Date: 2021-01-12 05:08:16
Message-ID: CAA4eK1+q1=gXx7iwW=dGt0LNQJkDW+ZpRGmKNXK2k9QLjGr=vA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, Jan 7, 2021 at 2:55 PM PG Bug reporting form
<noreply(at)postgresql(dot)org> wrote:
>
> The following bug has been logged on the website:
>
> Bug reference: 16812
> Logged by: Mayur B.
> Email address: mayur555b(at)protonmail(dot)com
> PostgreSQL version: 12.3
> Operating system: Ubuntu 16.04.6 LTS
> Description:
>
> Hi,
> We started receiving the logical decoding error :
> ERROR: could not map filenode "base/16437/140990927" to relation OID
>
> Database is PG 12.3 and Ubuntu 16.04.6 LTS. There is no "vacuum full" or
> CLUSTER happening. What could be other sources of this error?
>

It is not clear to me how else this error can happen. However, I think
this can happen due to some re-write of mapped relations as we don't
maintain historic-view for mapped relations. Having said that, as far
as I understand this shouldn't cause any problem because we anyway
don't decode updates to catalog relations and we would have anyway
skipped this operation. I am not sure maybe this could have been a LOG
instead of ERROR.

One way to figure what is going on here is to add a LOG message in
apply_map_update to see the change relationId and then we might be
able to track which exact operation has changed this. The other
possibility could be to use pg_waldump to figure out the WAL record
which leads to this error (maybe with the help of LSN, we can identify
that).

--
With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2021-01-12 06:34:28 Re: BUG #16577: Segfault on altering a table located in a dropped tablespace
Previous Message Justin Pryzby 2021-01-12 04:13:52 Re: pg_upgrade test for binary compatibility of core data types