Re: Adding REPACK [concurrently] - Mailing list pgsql-hackers

From Antonin Houska
Subject Re: Adding REPACK [concurrently]
Date
Msg-id 230042.1775577676@localhost
Whole thread Raw
In response to Re: Adding REPACK [concurrently]  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> wrote:

> On 2026-04-07 17:38:24 +0200, Antonin Houska wrote:
> > The REPACK plugin only deforms tuples and writes them to a file, so I think
> > that things like this should not happen.
>
> You don't need to do it yourself.  It just requires a shared_preload_library
> extension to register a relcache invalidation callback that accesses shared
> catalog.
>
> It's only kind of an accident that we don't have a case today that accesses
> shared catcaches during a relcache build in core (I'm not even sure there's
> nothing). You'd just need somebody to add e.g. relcache caching for
> publications for that to change. Or look up information about a reloption in
> pg_parameter_acl. Or lookup tablespace configuration.
>
>
> > However, I admit that an option that allows the plugin developer to declare
> > "I don't need shared catalogs" may be considered deceptive.
>
> At the very least it would need to be a runtime check rather than just an
> assert. This would much more likely to be hit in production because otherwise
> it's probably hard to hit the case where shared invalidations happen in the
> wrong moment.  And the consequences are corrupted caches, which could cause
> all kinds of havoc.
>
>
> But I think this may need more infrastructure / deeper analysis than what we
> can do right now.

ok, thanks a lot for having looked at it.

--
Antonin Houska
Web: https://www.cybertec-postgresql.com



pgsql-hackers by date:

Previous
From: Xuneng Zhou
Date:
Subject: Re: Implement waiting for wal lsn replay: reloaded
Next
From: Jacob Champion
Date:
Subject: Re: [PATCH] OAuth: fix performance bug with stuck multiplexer events