Re: pgsql: Avoid invalidating all RelationSyncCache entries on publication

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Amit Kapila <akapila(at)postgresql(dot)org>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pgsql: Avoid invalidating all RelationSyncCache entries on publication
Date: 2025-03-17 16:05:22
Message-ID: CA+Tgmoa+GkGNZ86QmqyuOCHWaBkOEJAEPfghEQ1d8_+KudVknw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Thu, Mar 13, 2025 at 12:00 AM Amit Kapila <akapila(at)postgresql(dot)org> wrote:
> Avoid invalidating all RelationSyncCache entries on publication rename.
>
> On Publication rename, we need to only invalidate the RelationSyncCache
> entries corresponding to relations that are part of the publication being
> renamed.
>
> As part of this patch, we introduce a new invalidation message to
> invalidate the cache maintained by the logical decoding output plugin. We
> can't use existing relcache invalidation for this purpose, as that would
> unnecessarily cause relcache invalidations in other backends.

This seems like too much infrastructure for a niche optimization. If
there are plans to use this new invalidation message type to optimize
a bunch of other cases, then maybe it's worth it, but adding this just
to cover the presumably-rare case of ALTER PUBLICATION .. RENAME
doesn't seem worth it to me.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2025-03-17 16:53:55 pgsql: Unify wording of user-facing "row security" messages.
Previous Message Michael Paquier 2025-03-17 05:08:06 pgsql: Fix inconsistent quoting for some options in TAP tests

Browse pgsql-hackers by date

  From Date Subject
Next Message Bertrand Drouvot 2025-03-17 16:11:27 Re: Draft for basic NUMA observability
Previous Message Jacob Champion 2025-03-17 15:50:39 Re: libpq: Process buffered SSL read bytes to support records >8kB on async API