Re: "unexpected duplicate for tablespace" problem in logical replication
Masahiko Sawada <sawada.mshk@gmail.com>
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Robert Haas <robertmhaas@gmail.com>,
Kyotaro Horiguchi <horikyota.ntt@gmail.com>, vignesh21@gmail.com, wangsh.fnst@fujitsu.com, osumi.takamichi@fujitsu.com, pgsql-bugs@lists.postgresql.org, Andres Freund <andres@anarazel.de>
Date: 2024-07-24T21:51:20Z
Lists: pgsql-bugs
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Ignore temporary relations in RelidByRelfilenumber()
- 30b32b08c9e9 13.23 landed
- 222130edd81f 14.20 landed
- ec471008c8fc 15.15 landed
- ab874faaa1f3 16.11 landed
- dcdc95cb4d4c 17.7 landed
- 86831952ad60 18.0 landed
- ef03ea01fe47 19 (unreleased) landed
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. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com