Re: "unexpected duplicate for tablespace" problem in logical replication

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: vignesh21(at)gmail(dot)com
Cc: sawada(dot)mshk(at)gmail(dot)com, wangsh(dot)fnst(at)fujitsu(dot)com, osumi(dot)takamichi(at)fujitsu(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: "unexpected duplicate for tablespace" problem in logical replication
Date: 2024-01-12 08:37:46
Message-ID: 20240112.173746.1710988914918513917.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

At Mon, 8 Jan 2024 10:32:03 +0530, vignesh C <vignesh21(at)gmail(dot)com> wrote in
> I have changed the status to "Waiting on Author" as the points raised
> by Masahiko Sawada-san is pending.

Oops! This slipped off from my mind. Thank you for the reminder.

> On Tue, 19 Apr 2022 at 11:54, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> > > What do you think about this direction?
> >
> > Sounds good to me. If we go in this direction, probably we also need
> > to change the cache checks in RelidByRelfilenode() so that we
> > prioritize non-temporary relations. Otherwise, we will end up
> > returning the OID of temporary relation if it's already cached.

Maybe. It might be better for the cache not to register temprary
relations at all.

> > Another idea I came up with is that we have RelidByRelfilenode() check
> > only non-temporary relations by adding relpersistence !=
> > RELPERSISTENCE_TEMP to the scan key.

I'm not sure it is good considering the case pg_relationumber_relation
for a temporary relation.

> > If we want to support temporary
> > relations too, I think that, in v16, we can add relpersistence to
> > RelidByRelfilenode() as a function argument (and a flag to
> > pg_filenode_relation() accordingly) so that the user can get the name
> > of the temporary relation by like pg_filenode_relation(0, 16386,
> > true). On the other hand, in back branches, if an application is using
> > pg_filenode_relation() to get the name of temporary relations, it
> > would break it.

Agreed. So, the attachd files are the patches for the master and older
versions respectively.

If there is a concern with the patch for the master, the parameter
handling of pg_filenode_relation might be not good. If the feature of
searching for relations regardless of their persistence is
unnecessary, it could be simplified. (Anyway it lacks documentation at
all).

Also, while the patch for version 11 is attached, I am unable to build
this version on my system (although I haven't investigated this
deeply, but I'm on Rocky 9 now).

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

Attachment Content-Type Size
RelidByRelfilenumber_prefer_perm_rels_master.patch text/x-patch 6.2 KB
RelidByRelfilenumber_prefer_perm_rels_15-16.patch text/x-patch 2.3 KB
RelidByRelfilenumber_prefer_perm_rels_12-14.patch text/x-patch 2.1 KB
RelidByRelfilenumber_prefer_perm_rels_11.patch text/x-patch 2.2 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Alexander Lakhin 2024-01-12 13:00:01 Re: BUG #17798: Incorrect memory access occurs when using BEFORE ROW UPDATE trigger
Previous Message PG Bug reporting form 2024-01-12 08:37:02 BUG #18286: "ERROR: could not open relation with OID 16391" error was encountered when reindexing