Re: Including replication slot data in base backups - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Including replication slot data in base backups
Date
Msg-id 20140401145926.GB3750@awork2.anarazel.de
Whole thread Raw
In response to Re: Including replication slot data in base backups  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Including replication slot data in base backups
List pgsql-hackers
On 2014-04-01 16:45:46 +0200, Magnus Hagander wrote:
> On Tue, Apr 1, 2014 at 2:24 PM, Michael Paquier
> <michael.paquier@gmail.com>wrote:
> 
> > Hi all,
> >
> > As of now, pg_basebackup creates an empty repository for pg_replslot/
> > in a base backup, forcing the user to recreate slots on other nodes of
> > the cluster with pg_create_*_replication_slot, or copy pg_replslot
> > from another node. This is not really user-friendly especially after a
> > failover where a given slave may not have the replication slot
> > information of the master that it is replacing.

What exactly is your usecase for copying the slots?

> > The simple patch attached adds a new option in pg_basebackup, called
> > --replication-slot, allowing to include replication slot information
> > in a base backup. This is done by extending the command BASE_BACKUP in
> > the replication protocol.

> --replication-slots would be a better name (plural), or probably
> --include-replication-slots. (and that comment also goes for the
> BASE_BACKUP syntax and variables)

I vote for --include-replication-slots.

> But. If you want to solve the failover case, doesn't that mean you need to
> include it in the *replication* stream and not just the base backup?

They pretty fundamentally can't be in the replication stream - there's
no way to make that work with cascading setups and such.

> Otherwise, what you're sending over might well be out of date set of slots
> once the failover happens? What if the set of replication slots change
> between the time of the basebackup and the failover?

An out of date slot doesn't seem really harmful for the failover
case. All that will happen is that it will reserve too many
resources. That should be fine.

> It's not too late to fix omissions in 9.4 features though, if we consider
> it that. Which I think this could probably be considered as - if we think
> the solution is the right one.

Yea, I think adding this would be fine if we deem it necessary.

Greetings,

Andres Freund

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



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: pg_stat_statements cluttered with "DEALLOCATE dbdpg_p*"
Next
From: Adrian Vondendriesch
Date:
Subject: Re: WIP patch for Todo Item : Provide fallback_application_name in contrib/pgbench, oid2name, and dblink