Re: "unexpected duplicate for tablespace" problem in logical replication
От | Andres Freund |
---|---|
Тема | Re: "unexpected duplicate for tablespace" problem in logical replication |
Дата | |
Msg-id | bysczui5rgxmrnzeq6jczo3u5g2lwallqrduubnayq2g5dhzwh@l64sg7jl52sf обсуждение исходный текст |
Ответ на | Re: "unexpected duplicate for tablespace" problem in logical replication (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>) |
Ответы |
Re: "unexpected duplicate for tablespace" problem in logical replication
|
Список | 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 по дате отправления: