Re: DROP SUBSCRIPTION, query cancellations and slot handling

From: Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: DROP SUBSCRIPTION, query cancellations and slot handling
Date: 2017-04-20 14:19:29
Message-ID: 2ae51bc0-d135-2cbe-1c05-26c8c6cfb39f@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 20/04/17 14:41, Michael Paquier wrote:
> On Thu, Apr 20, 2017 at 8:47 PM, Petr Jelinek
> <petr(dot)jelinek(at)2ndquadrant(dot)com> 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 created. This is a confusing
> experience for users.
>
> 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.
>

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.

Any other potential errors will be out of control of CreateSubscription
anyway.

Thoughts?

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2017-04-20 14:27:30 Re: statement_timeout is not working as expected with postgres_fdw
Previous Message Dilip Kumar 2017-04-20 14:01:51 Re: Logical replication ApplyContext bloat