Skip site navigation (1) Skip section navigation (2)

Re: register/unregister standby Re: Synchronous replication

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Joshua Tolley <eggyknap(at)gmail(dot)com>, Yeb Havinga <yebhavinga(at)gmail(dot)com>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: register/unregister standby Re: Synchronous replication
Date: 2010-09-01 14:39:53
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 30/08/10 15:14, Fujii Masao wrote:
> I think that the advantage of registering standbys is that we can
> specify which WAL files the master has to keep for the upcoming
> standby. IMO, it's usually called together with pg_start_backup
> as follows:
>      SELECT register_standby('foo', pg_start_backup())
> This requests the master keep to all the WAL files following the
> backup starting location which pg_start_backup returns.

Hmm, that's clever. I was thinking that you'd initialize the standby 
from an existing backup, and in that context the standby would not need 
to connect to the master except via the replication connection. To take 
a base backup, you'll need not only that but also access to the 
filesystem in the master, ie. shell access.

There's been some talk of being able to stream a base backup over the 
replication connection too, which would be extremely handy. And that 
makes my point even stronger that registering a standby should be 
possible via the replication connection.

Of course, you could well expose the functionality as both a built-in 
function and a command in replication mode, so this detail isn't really 
that important right now.

   Heikki Linnakangas

In response to


pgsql-hackers by date

Next:From: Michael MeskesDate: 2010-09-01 14:41:07
Subject: Re: ECPG dynamic cursor fix for UPDATE/DELETE ... WHERE CURRENT OF :curname
Previous:From: PostgreSQL - Hans-Jürgen SchönigDate: 2010-09-01 14:28:06
Subject: Re: Path question

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group