Re: [COMMITTERS] pgsql: Add support for temporary replication slots
От | Andres Freund |
---|---|
Тема | Re: [COMMITTERS] pgsql: Add support for temporary replication slots |
Дата | |
Msg-id | 20161213004903.iito2pefdrrjgny5@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Add support for temporary replication slots (Petr Jelinek <petr.jelinek@2ndquadrant.com>) |
Список | pgsql-committers |
On 2016-12-13 01:42:48 +0100, Petr Jelinek wrote: > On 13/12/16 01:40, Tom Lane wrote: > > Petr Jelinek <petr.jelinek@2ndquadrant.com> writes: > >> On 13/12/16 00:39, Tom Lane wrote: > >>> Hm, buildfarm says this didn't fix it. Where exactly does the dropping > >>> of the slot happen ... is it not complete by the time the backend exits? > > > >> Yes, I've seen. The cleanup of slots is done in ProcKill(), I wonder, > >> since it's on_shmem_exit hook, and the pgstat_beshutdown_hook is as > >> well, maybe the pgstat_beshutdown_hook is called before ProcKill and the > >> query is lucky to hit right in between. > > > > Hm. That seems like a pretty bogus place to do it. An awful lot of the > > backend infrastructure is already gone by then, if I recall the ordering > > correctly. Maybe ShutdownPostgres would be a saner place; but it really > > depends on what you think the module layering is for this facility. > > I would definitely not think it is proc.c's responsibility, though. > > > > Well, the problem is that that's the place where the currently active > slot is released (if there was an active one). So we'd need to move that > part somewhere else as well. I am not sure what's the reasoning for > releasing it at that specific spot so CCing Andres. Why don't we just instead make the loop over pg_replication_slots? Andres
В списке pgsql-committers по дате отправления: