Re: Replication slot drop message is sent after pgstats shutdown.
От | Andres Freund |
---|---|
Тема | Re: Replication slot drop message is sent after pgstats shutdown. |
Дата | |
Msg-id | 20210901033721.bkmgfgblzfnthzoi@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Replication slot drop message is sent after pgstats shutdown. (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
Re: Replication slot drop message is sent after pgstats shutdown.
|
Список | pgsql-hackers |
Hi, On 2021-09-01 10:05:18 +0900, Masahiko Sawada wrote: > On Wed, Sep 1, 2021 at 2:39 AM Andres Freund <andres@anarazel.de> wrote: > > On 2021-08-31 18:34:12 +0900, Kyotaro Horiguchi wrote: > > > At Tue, 31 Aug 2021 17:14:45 +0900, Masahiko Sawada <sawada.mshk@gmail.com> wrote in > > > > On Tue, Aug 31, 2021 at 2:34 PM Andres Freund <andres@anarazel.de> wrote: > > > > I've attached the patch that moves them to its own > > > > before_shmem_exit(). Unless I missed to register the callback it works > > > > the same as before except for where to release and clean up the slots. > > > > > > Is there any reason we need to register the callback dynamically? It > > > seems to me what we need to do here is to call the functions at > > > before-shmem-exit. > > > > +1. I'd just add a ReplicationSlotInitialize() to BaseInit(). > > +1. But BaseInit() is also called by auxiliary processes, which seems > not necessary. So isn't it better to add it to InitPostgres() or > InitProcess()? -0.5 - I think we should default to making the environments more similar, rather than the opposite. With exceptions for cases where that'd cause overhead or undue complexity. Which I don't see here? Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: