From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | peter(dot)eisentraut(at)2ndquadrant(dot)com |
Cc: | robertmhaas(at)gmail(dot)com, magnus(at)hagander(dot)net, michael(dot)banck(at)credativ(dot)de, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Create replication slot in pg_basebackup if requested and not yet present |
Date: | 2017-03-22 07:09:25 |
Message-ID: | 20170322.160925.89175016.horiguchi.kyotaro@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello, I favor this feature.
At Wed, 22 Mar 2017 00:18:19 -0400, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote in <1f5daba9-773d-9281-5608-37f049025bb3(at)2ndquadrant(dot)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.kyotaro@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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2017-03-22 07:13:32 | Re: [PATCH] Transaction traceability - txid_status(bigint) |
Previous Message | Rafia Sabih | 2017-03-22 07:00:22 | Re: Enabling parallelism for queries coming from SQL or other PL functions |