Re: Create replication slot in pg_basebackup if requested and not yet present

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>, 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-11 07:18:26
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On Fri, Sep 08, 2017 at 08:41:56AM +0200, Michael Banck wrote:
> 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:
> > > > >
> > > > >
> > > >
> > > > 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?

New reworked and rebased patch attached, including setting RESERVE_WAL
for physical replication slots and the additional TAP test comparing the
restart_lsn with the checkpoint_lsn.

The only thing from the above I did not change yet is the removal of the
temporary slots creation message in verbose mode. I have the feeling
knowing the temporary slot name could be helpful for debugging and
pg_basebackup is already pretty chatty in verbose mode so I preferred to
keep it, but I can remove it of course if that is the consensus.


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

Attachment Content-Type Size
0001-Add-option-to-create-a-replication-slot-in-pg_baseba-v5.patch text/x-diff 12.8 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2017-09-11 07:23:09 Re: Partition-wise join for join between (declaratively) partitioned tables
Previous Message Amit Khandekar 2017-09-11 07:16:06 Re: expanding inheritance in partition bound order