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

Re: [COMMITTERS] pgsql: If recovery_target_timeline is set to 'latest' and standby mode

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: If recovery_target_timeline is set to 'latest' and standby mode
Date: 2011-03-07 19:20:58
Message-ID: AANLkTimgQuFzhb79oxp4dtCEcOSRLcXCDW=Rt2ESQiQ2@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
On Mon, Mar 7, 2011 at 20:16, Heikki Linnakangas
<heikki(dot)linnakangas(at)iki(dot)fi> wrote:
> If recovery_target_timeline is set to 'latest' and standby mode is enabled,
> periodically rescan the archive for new timelines, while waiting for new WAL
> segments to arrive. This allows you to set up a standby server that follows
> the TLI change if another standby server is promoted to master. Before this,
> you had to restart the standby server to make it notice the new timeline.

Can we make recovery_target_timeline='latest' the default when we are
in standby mode? That would suddenly make it a lot easier to "repoint
a slave" after a switchover...

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

In response to

Responses

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2011-03-07 19:24:56
Subject: Re: Re: [COMMITTERS] pgsql: If recovery_target_timeline is set to 'latest' and standby mode
Previous:From: Simon RiggsDate: 2011-03-07 19:17:25
Subject: Re: How should the primary behave when the sync standby goes away? Re: Sync Rep v17

pgsql-committers by date

Next:From: Heikki LinnakangasDate: 2011-03-07 19:24:56
Subject: Re: Re: [COMMITTERS] pgsql: If recovery_target_timeline is set to 'latest' and standby mode
Previous:From: Heikki LinnakangasDate: 2011-03-07 19:16:05
Subject: pgsql: If recovery_target_timeline is set to 'latest' and standbymode

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