Re: pg_basebackup --slot=SLOTNAME -X stream

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_basebackup --slot=SLOTNAME -X stream
Date: 2014-03-18 14:08:57
Message-ID: CA+TgmoZi7rrJxSiZ62LfH0WjM3rc1MKjBRuQRaAoCULbozG-0A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 18, 2014 at 9:46 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> I started working on that at some point long ago, but never got far enough.
>
> Right now, it seems the right way to do that is to somehow reimplement it on
> top of a "lightweight slot" that gets automatically destroyed when
> pg_basebackup stops.
>
> But as Andres said, there's a little more to it. You'd want the slot to be
> created in the connection that does BASE_BACKUP, then used by the
> replication client side, and then destroyed by BASE_BACKUP. But you also
> want it auto-destroyed if the BASE_BACKUP connection gets terminated for
> example..

The slot machinery already has provision for drop-on-release slots.
But I don't think we expose that at the protocol level in any way just
yet. CREATE_REPLICATION_SLOT ... TEMPORARY or something might not be
that hard, but at this point I think it's too late to invent new
things for 9.4. I am hoping for a raft of improvements to the slot
stuff for next release, but trying to do that now seems like pushing
our luck.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2014-03-18 14:15:11 Re: pg_archivecleanup bug
Previous Message Bruce Momjian 2014-03-18 14:06:51 Re: pg_archivecleanup bug