Re: [HACKERS] DROP SUBSCRIPTION, query cancellations and slot handling

2017-04-21 Thread Peter Eisentraut
On 4/20/17 22:57, Michael Paquier wrote: > On Fri, Apr 21, 2017 at 11:34 AM, Petr Jelinek > wrote: >> On 20/04/17 23:30, Peter Eisentraut wrote: >>> On 4/20/17 10:19, Petr Jelinek wrote: Hmm well since this only affects the synchronization of table

Re: [HACKERS] DROP SUBSCRIPTION, query cancellations and slot handling

2017-04-20 Thread Michael Paquier
On Fri, Apr 21, 2017 at 11:34 AM, Petr Jelinek wrote: > On 20/04/17 23:30, Peter Eisentraut wrote: >> On 4/20/17 10:19, Petr Jelinek wrote: >>> Hmm well since this only affects the synchronization of table >>> states/names, I guess we could just simply do that before

Re: [HACKERS] DROP SUBSCRIPTION, query cancellations and slot handling

2017-04-20 Thread Petr Jelinek
On 20/04/17 23:30, Peter Eisentraut wrote: > On 4/20/17 10:19, Petr Jelinek wrote: >> Hmm well since this only affects the synchronization of table >> states/names, I guess we could just simply do that before we create the >> slot as there is no expectancy of consistency between slot and the table

Re: [HACKERS] DROP SUBSCRIPTION, query cancellations and slot handling

2017-04-20 Thread Peter Eisentraut
On 4/20/17 10:19, Petr Jelinek wrote: > Hmm well since this only affects the synchronization of table > states/names, I guess we could just simply do that before we create the > slot as there is no expectancy of consistency between slot and the table > list snapshot. I suppose that wouldn't hurt.

Re: [HACKERS] DROP SUBSCRIPTION, query cancellations and slot handling

2017-04-20 Thread Peter Eisentraut
On 4/20/17 08:41, Michael Paquier wrote: > As subscription is a self-contained concept, it seems to me that any > errors happening should at least try to do some cleanup action before > just giving up processing, that would be a less frustrating > experience. This is the way it's designed. The

Re: [HACKERS] DROP SUBSCRIPTION, query cancellations and slot handling

2017-04-20 Thread Petr Jelinek
On 20/04/17 14:41, Michael Paquier wrote: > On Thu, Apr 20, 2017 at 8:47 PM, Petr Jelinek > wrote: >> Or you can drop the slot manually on upstream. > > Sure, but the point here is that if for example users have > client_min_messages set at least at warning, they

Re: [HACKERS] DROP SUBSCRIPTION, query cancellations and slot handling

2017-04-20 Thread Michael Paquier
On Thu, Apr 20, 2017 at 8:47 PM, Petr Jelinek wrote: > Or you can drop the slot manually on upstream. Sure, but the point here is that if for example users have client_min_messages set at least at warning, they may have no idea that an underlying slot has been

Re: [HACKERS] DROP SUBSCRIPTION, query cancellations and slot handling

2017-04-20 Thread Petr Jelinek
On 20/04/17 09:35, Michael Paquier wrote: > On Thu, Apr 20, 2017 at 4:22 PM, Michael Paquier > wrote: >> I am adding an open item. > > Just adding something... When a subscription is created, if the step > synchronizing tables fails then CREATE SUBSCRIPTION fails but

Re: [HACKERS] DROP SUBSCRIPTION, query cancellations and slot handling

2017-04-20 Thread Petr Jelinek
On 20/04/17 09:22, Michael Paquier wrote: > Hi, > > I have noticed the following behavior with DROP SUBSCRIPTION followed > by a cancel request. If the remote replication slot is dropped, the > subscription may still be present locally: > =# CREATE SUBSCRIPTION mysub CONNECTION 'port=5432

Re: [HACKERS] DROP SUBSCRIPTION, query cancellations and slot handling

2017-04-20 Thread Michael Paquier
On Thu, Apr 20, 2017 at 4:22 PM, Michael Paquier wrote: > I am adding an open item. Just adding something... When a subscription is created, if the step synchronizing tables fails then CREATE SUBSCRIPTION fails but the slot remains present on the publisher side, so