On 2015-07-29 12:47:01 +0100, Simon Riggs wrote:
> On 29 July 2015 at 11:43, Andres Freund <andres@anarazel.de> wrote:
>
> > On 2015-07-29 09:17:04 +0100, Simon Riggs wrote:
> > > On 29 July 2015 at 09:09, Andres Freund <andres@anarazel.de> wrote:
> > > > The point of using a temporary slot is to not have a
> > > > leftover slot afterwards, reserving resources. Especially important if
> > > > the basebackup actually failed...
> > > >
> > >
> > > Creating a slot and then deleting it if the session disconnects does not
> > > successfully provide the functionality desired above.
> >
> > Uh? If you create the slot, start streaming, and then start the
> > basebackup, it does. It does *not* guarantee that the base backup can be
> > converted into a replica, but it's sufficient to guarantee it can
> > brought out of recovery.
> >
>
> Perhaps we are misunderstanding the word "it" here. "it can be brought out
> of recovery"?
The finished base backup.
> You appear to be saying that a backup that disconnects before completion is
> useful in some way. How so?
I'm not trying to say that at all.
As far as I understand this subthread the goal is to have a
pg_basebackup that internally creates a slot, so it can guarantee that
all the required WAL is present till streamed out by -X
stream/fetch. The problem with just creating a slot is that it'd "leak"
if pg_basebackup is killed, or the connection breaks. The idea with the
ephemeral slot is that it'd automatically kept alive until the base
backup is complete, but would also automatically be dropped if the base
backup fails.
Makes sense?
We pretty much have all the required infrastructure for that in slot.c,
it's just not exposed to the replication protocol.
Greetings,
Andres Freund