Обсуждение: pg_basebackup --slot=SLOTNAME -X stream
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? Regards, -- Fujii Masao
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
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
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: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.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?
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