From: | Michael Banck <michael(dot)banck(at)credativ(dot)de> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Create replication slot in pg_basebackup if requested and not yet present |
Date: | 2017-09-08 06:41:56 |
Message-ID: | 1504852916.25868.16.camel@credativ.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
Am Mittwoch, den 06.09.2017, 12:22 -0400 schrieb Peter Eisentraut:
> On 8/18/17 05:28, Michael Banck wrote:
> > > > Rebased, squashed and slighly edited version attached. I've added this
> > > > to the 2017-07 commitfest now as well:
> > > >
> > > > https://commitfest.postgresql.org/14/1112/
> > >
> > > Can you rebase this past some conflicting changes?
> >
> > Thanks for letting me know, PFA a rebased version.
>
> I have reviewed the thread so far. I think there is general agreement
> that something like this would be good to have.
>
> I have not found any explanation, however, why the "if not exists"
> behavior is desirable, let alone as the default. I can only think of
> two workflows here: Either you have scripts for previous PG versions
> that create the slot externally, in which can you omit --create, or you
> use the new functionality to have pg_basebackup create the slot. I
> don't see any use for pg_basebackup to opportunistically use a slot if
> it happens to exist. Even if there is one, it should not be the
> default. So please change that.
Ok, I tried to research why that was the case and couldn't find any
trace of a discussion either.
So we should just error out in CreateReplicationSlot() in case a slot
exists, right? I think having yet another option like --create-if-not-
exists does not sound needed from what you wrote above.
> A minor point, I suggest to print the message about the replication slot
> being created *after* the slot has been created. This aligns with how
> logical replication subscriptions work.
Ok.
> I don't see the need for printing a message about temporary slots.
> Since they are temporary, they will go away automatically, so there is
> nothing the user needs to know there.
Ok. I thought I'd remembered some request around having this reported
always (maybe from Magnus), but I couldn't find anything in the prior
discussions either.
If we don't print the message for temporary slots, then the
CreateReplicationSlot() refactoring and the addition of the
temp_replication_slot argument would be no longer needed, or is this
something useful on its own?
Thanks,
Michael
--
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166 9901-171
Fax: +49 2166 9901-100
Email: michael(dot)banck(at)credativ(dot)de
credativ GmbH, HRB Mönchengladbach 12080
USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Dolgov | 2017-09-08 06:58:23 | Re: log_destination=file |
Previous Message | Amit Langote | 2017-09-08 06:35:20 | Re: path toward faster partition pruning |