From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: logical replication syntax (was DROP SUBSCRIPTION, query cancellations and slot handling) |
Date: | 2017-05-09 05:07:53 |
Message-ID: | 35f3592b-8582-e348-1823-f8edfcf03ba3@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 5/8/17 23:23, Peter Eisentraut wrote:
> The way this uses RESTRICT and CASCADE appears to be backwards from its
> usual meaning. Normally, CASCADE when dropping an object that is still
> used by others will cause those other objects to be dropped. The
> equivalent here would be DROP REPLICATION SLOT + CASCADE would drop the
> subscription.
>
> What we want to simulate instead is an "auto" dependency of the slot on
> the subscription. So you can drop the slot separately (subject to other
> restrictions), and it is dropped automatically when the subscription is
> dropped. To avoid that, you can disassociate the slot from the
> subscription, which you have implemented.
>
> I think we can therefore do without RESTRICT/CASCADE here. If a slot is
> associated with the subscription, it should be there when we drop the
> subscription. Otherwise, the user has to disassociate the slot and take
> care of it manually. So just keep the "cascade" behavior.
>
> Similarly, I wouldn't check first whether the slot exists. If the
> subscription is associated with the slot, it should be there.
Here is your patch amended for that.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment | Content-Type | Size |
---|---|---|
v2-0001-Remove-the-NODROP-SLOT-option-from-DROP-SUBSCRIPT.patch | invalid/octet-stream | 31.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2017-05-09 05:21:55 | Re: Re: [Pkg-postgresql-public] Debian "postgresql-common" config check issue with pg10 |
Previous Message | Peter Eisentraut | 2017-05-09 03:35:34 | Re: Should pg_current_wal_location() become pg_current_wal_lsn() |