Re: "unexpected duplicate for tablespace" problem in logical replication
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, vignesh C <vignesh21@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, wangsh.fnst@fujitsu.com,
osumi.takamichi@fujitsu.com, pgsql-bugs@lists.postgresql.org
Date: 2025-09-18T12:17:49Z
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
Hi, On 2025-09-18 17:37:10 +0530, Ashutosh Bapat wrote: > From 6a3562b4ac8917c8b577797e5468416a90cc04f5 Mon Sep 17 00:00:00 2001 > From: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> > Date: Thu, 18 Sep 2025 17:24:09 +0530 > Subject: [PATCH] Negative RelfilenumberMap cache entries from > pg_filenode_relation() > > RelidByRelfilenumber() adds negative entries to the cache. It has three > users, logical replication, autoprewarm and pg_filenode_relation(). The > first two need negative entries in the cache in case they happen to > lookup non-existent mapping again and again. However such mappings will > be smaller in number and usually come from some database object e.g. WAL > or autoprewarm metadata. > > But pg_filenode_relation(), which is SQL callable, may be invoked many > times with invalid tablespace and relfilenode pairs, causing the cache > to be bloated with negative cache entries. This can be used as a denial > of service attack since any user can execute it. This commit avoids such > a bloat. I don't really understand why this is worth fixing for the relfilenode stuff specifically - isn't this true for just about *all* of our caches? Many, if not most, can be reached via SQL? Greetings, Andres Freund