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 user=mpaquier > dbname=mpaquier' PUBLICATION mypub, insert_only; > NOTICE: 00000: created replication slot "mysub" on publisher > LOCATION: CreateSubscription, subscriptioncmds.c:408 > NOTICE: 00000: synchronized table states > LOCATION: CreateSubscription, subscriptioncmds.c:434 > CREATE SUBSCRIPTION > =# DROP SUBSCRIPTION mysub; > ^CCancel request sent > NOTICE: 00000: dropped replication slot "mysub" on publisher > LOCATION: DropSubscription, subscriptioncmds.c:873 > ERROR: 57014: canceling statement due to user request > LOCATION: ProcessInterrupts, postgres.c:2984 > > In this case the subscription is not dropped: > =# select subname from pg_subscription; > subname > --------- > mysub > (1 row) > But trying to issue once again a drop results in an error: > =# DROP SUBSCRIPTION mysub; > ERROR: XX000: could not drop the replication slot "mysub" on publisher > DETAIL: The error was: ERROR: replication slot "mysub" does not exist > LOCATION: DropSubscription, subscriptioncmds.c:869 > > A subscription with the same name cannot be created either, so there > is nothing that the user can do except drop manually the slot on the > publisher. It seems to me that the moment where the slot is created > should be a point of no-return: the subcription has to be dropped on > the replication slot is dropped on the remote. >
DROP SUBSCRIPTION mysub NODROP SLOT; -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
