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

From Robert Haas
Subject Re: [HACKERS] logical replication syntax (was DROP SUBSCRIPTION,query cancellations and slot handling)
Date
Msg-id CA+TgmoYvobB=85_K7JOdECjzzWS1Rnem-vTkp42r_8gFP0gitQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] logical replication syntax (was DROP SUBSCRIPTION,query cancellations and slot handling)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: [HACKERS] logical replication syntax (was DROP SUBSCRIPTION,query cancellations and slot handling)  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
List pgsql-hackers
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?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] logical replication syntax (was DROP SUBSCRIPTION,query cancellations and slot handling)
Next
From: Thomas Kellerer
Date:
Subject: Re: [HACKERS] CTE inlining