Re: Adding REPACK [concurrently]
| От | Antonin Houska |
|---|---|
| Тема | Re: Adding REPACK [concurrently] |
| Дата | |
| Msg-id | 230042.1775577676@localhost обсуждение |
| Ответ на | Re: Adding REPACK [concurrently] (Andres Freund <andres@anarazel.de>) |
| Список | 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 по дате отправления: