Hello, I favor this feature. At Wed, 22 Mar 2017 00:18:19 -0400, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote in <1f5daba9-773d-9281-5608-37f049025...@2ndquadrant.com> > On 3/21/17 15:34, Robert Haas wrote: > > So I tend to think that there should always be some explicit user > > action to cause the creation of a slot, like --create-slot-if-needed > > or --create-slot=name. That still won't prevent careless use of that > > option but it's less dangerous than assuming that a user who refers to > > a nonexistent slot intended to create it when, perhaps, they just > > typo'd it. > > I have the same concern.
A slot created as !immeediately_reserve (even though currently CREATE_REPLICATION_SLOT command doesn't seem to have the option) won't do such a trick but I agree to the point. I think that any explicit action is required unless any anticipated catastrophic end caused by remainig slots is evaded implicitly. Do ephemeral or temporary slots help this case? Otherwise, I'm proposing a patch to ignore restart-lsn of slots that let too many WALs to stay on. https://www.postgresql.org/message-id/20170228.122736.123383594.horiguchi.kyot...@lab.ntt.co.jp Instaed just ignoring restart-lsn, like Andres' suggestion, removing (or just disabling) a slot that is marked as 'auto-removable' with the same kind (including disconnection timeout) of trigger also will work. I had a similar annoyance with CREATE SUBSCRIPTION. It implicitly creates a slot on publisher and subscriber fails to have the same subscription after re-initialization. Of couse DROP SUBSCRIPTION doesn't help the case. Users don't have a clue to solution, I suppose. But this would be another topic. regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers