Masahiko Sawada <sawada.m...@gmail.com> writes: > On Sun, Sep 17, 2017 at 2:01 AM, Masahiko Sawada <sawada.m...@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
