On 13/12/16 01:49, Andres Freund wrote: > On 2016-12-13 01:42:48 +0100, Petr Jelinek wrote: >> On 13/12/16 01:40, Tom Lane wrote: >>> Petr Jelinek <[email protected]> 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? >
I mentioned that as possible solution upthread, I am only worried that the failure scenario is basically infinite loop. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
