Re: DROP SUBSCRIPTION hangs if sub is disabled in the same transaction

From: Arseny Sher <a(dot)sher(at)postgrespro(dot)ru>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: DROP SUBSCRIPTION hangs if sub is disabled in the same transaction
Date: 2017-09-22 11:52:48
Message-ID: 871smzeyr3.fsf@ars-thinkpad
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> writes:

> On Sun, Sep 17, 2017 at 2:01 AM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:

>> + <para>
>> + Since dropping a replication slot is not transactional, we cannot run
>> + <command>DROP SUBSCRIPTION</command> inside a transaction block if dropping
>> + the replication slot. Also, <command>DROP SUBSCRIPTOIN</command> stops the
>> + workers if the subscription got disabled in a transaction block even if
>> + the transaction rolls back.
>> + </para>
>
> Hmm, isn't there necessary to care and mention about this kind of
> inconsistent behavior in docs?

Well, docs already say that dropping sub with replication slot is
non-transactional, see 'Description' section of DROP SUBSCRIPTION. As
for the second sentence, normally launcher will restart the worker
immediately after ABORT: old worker wakes up the launcher on exit, the
launcher waits on pg_subscription lock and restarts the worker instantly
after the rollback. If we tell users that the workers are stopped after
DROP SUBSCRIPTION rollback, we should also say that they will be
restarted soon.

--
Arseny Sher

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2017-09-22 12:40:11 Re: visual studio 2017 build support
Previous Message Robert Haas 2017-09-22 11:49:42 Re: Improve catcache/syscache performance.