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

From Andres Freund
Subject Re: "unexpected duplicate for tablespace" problem in logical replication
Date
Msg-id bysczui5rgxmrnzeq6jczo3u5g2lwallqrduubnayq2g5dhzwh@l64sg7jl52sf
Whole thread Raw
In response to Re: "unexpected duplicate for tablespace" problem in logical replication  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Responses Re: "unexpected duplicate for tablespace" problem in logical replication
List pgsql-bugs
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



pgsql-bugs by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: "unexpected duplicate for tablespace" problem in logical replication
Next
From: Andres Freund
Date:
Subject: Re: "unexpected duplicate for tablespace" problem in logical replication