Re: "unexpected duplicate for tablespace" problem in logical replication - Mailing list pgsql-bugs

From vignesh C
Subject Re: "unexpected duplicate for tablespace" problem in logical replication
Date
Msg-id CALDaNm2b3XtaA6GQCD55z-eOyxXR2s_oBifesb7FgpKLJNYR0A@mail.gmail.com
Whole thread Raw
In response to Re: "unexpected duplicate for tablespace" problem in logical replication  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-bugs
On Thu, 25 Jul 2024 at 03:21, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Sun, Mar 17, 2024 at 11:35 PM Michael Paquier <michael@paquier.xyz> wrote:
> >
> > On Fri, Feb 02, 2024 at 10:49:17AM -0500, Robert Haas wrote:
> > > Andres, what do you think about this idea? I wonder if you just
> > > momentarily forgot about temporary relations when coding
> > > RelidByRelfilenumber -- because for that function to give well-defined
> > > answers with temporary relations included, it would need the backend
> > > ID as an additional argument.
> >
> >
> > Ignoring temporary relations entirely makes sense: one cannot get a
> > regclass from only a tablespace and a relfilenode, the persistence, as
> > well as a backend ID would also be required.  I've not checked the
> > patch in details, but it's to say that the idea to cut temporary
> > relations sounds rather right here.
>
> That makes sense to me too.
>
> Regarding the patch, filtering by the relpersistence in
> systable_getnext() loop seems to be good to me. Alternatively we can
> add "relpersistence == RELPERSISTENCE_TEMP" to the scan key. The patch
> would need regression tests too.

The attached patch adds a new test and resolves an existing test
failure. However, a downside is that we can no longer verify the
mapping of the temporary tables.

Regards,
Vignesh

Attachment

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #18861: Not able to download rpm package
Next
From: PG Bug reporting form
Date:
Subject: BUG #18865: pg_resetwal error: multitransaction offset (-O) must not be -1