Re: logical replication syntax (was DROP SUBSCRIPTION, query cancellations and slot handling)

On 02/05/17 16:14, Petr Jelinek wrote:
> On 02/05/17 15:31, Tom Lane wrote:
>> Petr Jelinek <petr.jelinek@2ndquadrant.com> writes:
>>> Let me expand, if we don't drop the slot by default when dropping
>>> subscription, we'll have a lot of users with dead slots laying around
>>> holding back WAL/catalog_xmin, that's really bad. If we do drop by
>>> default like now, we need option to not do that, neither RESTRICT, nor
>>> CASCADE fit that.
>>
>> I'm not sure which part of "you can't have an option in DROP" isn't
>> clear to you.  Whatever the default behavior is always has to work,
>> because that is what's going to happen during DROP OWNED BY, or
>> DROP DATABASE. 
> 
> You are saying it like there was some guarantee that those commands
> can't fail because of other objects. AFAIK for example drop database can
> trivially fail just because there is replication slot in it before PG10
> (IIRC Craig managed to fix that in 10 for unrelated reasons).
> 

Btw looks like I already forgot how this stuff behaves. Existence of
subscription currently also prevents DROP DATABASE (for same reason
active backends do).

DROP OWNED BY ignores SUBSCRIPTION too now, although I think it might
not be strictly necessary to stay that way.

But if we keep this behavior then the point about these two commands
cascading to subscriptions is largely moot.

-- 
  Petr Jelinek                  http://www.2ndQuadrant.com/
  PostgreSQL Development, 24x7 Support, Training & Services