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. I am adding an open item. Thanks, -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers