pg_basebackup --slot=SLOTNAME -X stream

Hi,

On 2014-03-18 22:25:05 +0900, Fujii Masao wrote:

Is there the explicit reason why --slot option that pg_receivexlog
already has has not been added into pg_basebackup? If not,
I'd like to support that option to eliminate the need to increase
wal_keep_segments for pg_basebackup. Thought?

I think to make the option really interesting for pg_basebackup we'd
need to make pg_basebackup create the slot, use it for streaming, and
then dump it afterwards. At the moment the walsender interface isn't
expressive enough to do that safely, without any chance of leaving a
slot behind on error. I don't have time to implement the necessary
scaffolding for 9.4.
I wouldn't mind a "raw" --slot argument, that requires the user to
create/drop the slot outside the calls to pg_basebackup. I just am not
sure how interesting it is to the majority of users.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 03/18/2014 03:25 PM, Fujii Masao wrote:

Hi,

Is there the explicit reason why --slot option that pg_receivexlog
already has has not been added into pg_basebackup? If not,
I'd like to support that option to eliminate the need to increase
wal_keep_segments for pg_basebackup. Thought?

That seems rather cumbersome. pg_basebackup is a run once, and then it
dies. The slot would have to be created before running pg_basebackup,
and destroyed manually.

It would make sense to provide a new option that would tell the server
to recycle segments until they've been sent to this client, or until the
client disconnects. But that would look quite different from
pg_receivexlog's --slot option.

- Heikki

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Mar 18, 2014 at 2:32 PM, Heikki Linnakangas <hlinnakangas@vmware.com

wrote:

On 03/18/2014 03:25 PM, Fujii Masao wrote:

Hi,

Is there the explicit reason why --slot option that pg_receivexlog
already has has not been added into pg_basebackup? If not,
I'd like to support that option to eliminate the need to increase
wal_keep_segments for pg_basebackup. Thought?

That seems rather cumbersome. pg_basebackup is a run once, and then it
dies. The slot would have to be created before running pg_basebackup, and
destroyed manually.

It would make sense to provide a new option that would tell the server to
recycle segments until they've been sent to this client, or until the
client disconnects. But that would look quite different from
pg_receivexlog's --slot option.

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..

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

On Tue, Mar 18, 2014 at 9:46 AM, Magnus Hagander <magnus@hagander.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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers