Masahiko Sawada <sawada.mshk@gmail.com> writes:
> On Sun, Sep 17, 2017 at 2:01 AM, Masahiko Sawada <sawada.mshk@gmail.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers