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.ba...@credativ.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers