Re: [HACKERS] logical replication syntax (was DROP SUBSCRIPTION,query cancellations and slot handling) - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: [HACKERS] logical replication syntax (was DROP SUBSCRIPTION,query cancellations and slot handling)
Date
Msg-id 20170502162556.6awiwpjypj63vnhz@alvherre.pgsql
Whole thread Raw
In response to Re: [HACKERS] logical replication syntax (was DROP SUBSCRIPTION,query cancellations and slot handling)  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
Responses Re: [HACKERS] logical replication syntax (was DROP SUBSCRIPTION,query cancellations and slot handling)  (Robert Haas <robertmhaas@gmail.com>)
Re: [HACKERS] logical replication syntax (was DROP SUBSCRIPTION,query cancellations and slot handling)  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
List pgsql-hackers
Petr Jelinek wrote:
> On 02/05/17 18:00, Robert Haas wrote:
> > On Tue, May 2, 2017 at 11:49 AM, Alvaro Herrera
> > <alvherre@2ndquadrant.com> wrote:
> >> Petr Jelinek wrote:
> >>> So the only way to fulfill the requirement you stated is to just not try
> >>> to drop the slot, ever, on DROP SUBSCRIPTION. That makes the default
> >>> behavior leave resources on upstream that will eventually cause that
> >>> server to stop unless user notices before. I think we better invent
> >>> something that limits how much inactive slots can hold back WAL and
> >>> catalog_xmin in this release as well then.
> >>
> >> I don't understand why isn't the default behavior to unconditionally
> >> drop the slot.  Why do we ever want the slot to be kept?
> > 
> > What if the remote server doesn't exist any more?
> 
> Or what if the slot is used by other subscription (because you restored
> dump containing subscriptions to another server for example), or you
> have server that does not have outside network access anymore, or many
> other reasons.

So there are two different scenarios: one is that you expect the slot
drop to fail for whatever reason; the other is that you want the slot to
be kept because it's needed for something else.  Maybe those two should
be considered separately.

1) keep the slot because it's needed for something else.  I see two options:  a) change the something else so that it
usesanother slot with the     same location.  Do we have some sort of "clone slot" operation?  b) have an option to
dissociatethe slot from the subscription prior     to the drop.
 

2) don't drop because we know it won't work.  I see two options:  c) ignore a drop slot failure, i.e. don't cause a
transactionabort.     An easy way to implement this is just add a PG_TRY block, but we     dislike adding those and not
re-throwingthe error.  d) rethink drop slot completely; maybe instead of doing it     immediately, it should be a
separatetask, so we first close the     current transaction (which dropped the subscription) and then we open     a
secondone to drop the slot, so that if the drop slot fails, the     subscription does not come back to life.
 

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: [HACKERS] logical replication syntax (was DROP SUBSCRIPTION,query cancellations and slot handling)
Next
From: David Fetter
Date:
Subject: Re: [HACKERS] CTE inlining