Re: [COMMITTERS] pgsql: Add support for temporary replication slots - Mailing list pgsql-committers

From Andres Freund
Subject Re: [COMMITTERS] pgsql: Add support for temporary replication slots
Date
Msg-id 20161213004903.iito2pefdrrjgny5@alap3.anarazel.de
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Add support for temporary replication slots  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: [COMMITTERS] pgsql: Add support for temporary replication slots
Next
From: Petr Jelinek
Date:
Subject: Re: [COMMITTERS] pgsql: Add support for temporary replication slots