Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns
Date
Msg-id CAD21AoCgYKRdW0u9ZT5mpcs_pme3OSvV2r099M3kfhQcDN+WFw@mail.gmail.com
Whole thread Raw
In response to Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns  (Jeremy Schneider <schneider@ardentperf.com>)
List pgsql-hackers
On Wed, Oct 13, 2021 at 7:55 AM Jeremy Schneider
<schneider@ardentperf.com> wrote:
>
> On 10/10/21 23:27, Masahiko Sawada wrote:
> >
> > After more thought, given DDLs are not likely to happen than DML in
> > practice, ...
>
> I haven't looked closely at the patch, but I'd be careful about
> workloads where people create and drop "temporary tables". I've seen
> this pattern used a few times, especially by developers who came from a
> SQL server background, for some reason.

True. But since the snapshot builder is designed on the same
assumption it would not be problematic. It keeps track of the
committed catalog modifying transaction instead of keeping track of
all running transactions. See the header comment of snapbuild.c

Regards,

-- 
Masahiko Sawada
EDB:  https://www.enterprisedb.com/



pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: Missing log message in recoveryStopsAfter() for RECOVERY_TARGET_TIME recovery target type
Next
From: Michael Paquier
Date:
Subject: Re: BUG #17220: ALTER INDEX ALTER COLUMN SET (..) with an optionless opclass makes index and table unusable