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

Tracking latest timeline in standby mode

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Tracking latest timeline in standby mode
Date: 2010-10-27 14:42:24
Message-ID: 4CC83A50.7070807@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
At the moment, when you specify recovery_target_timeline='latest', we 
scan for the latest timeline at the beginning of recovery, and pick that 
as the target. If new timelines appear during recovery, we stick to the 
target chosen in the beginning, the new timelines are ignored. That's 
undesirable if you have one master and two standby servers, and failover 
happens to one of the standbys. The other standby won't automatically 
start tracking the new TLI created by the promoted new master, it 
requires a restart to notice.

This was discussed a while ago: 
http://archives.postgresql.org/pgsql-hackers/2010-10/msg00620.php

More work needs to be done to make that work over streaming replication, 
sending history files over the wire, for example, but let's take baby 
steps. At the very minimum the startup process should notice new 
timelines appearing in the archive. The attached patch does that.

Comments?

A related issue is that we should have a check for the issue I also 
mentioned in the comments:

> 	/*
> 	 * If the current timeline is not part of the history of the
> 	 * new timeline, we cannot proceed to it.
> 	 *
> 	 * XXX This isn't foolproof: The new timeline might have forked from
> 	 * the current one, but before the current recovery location. In that
> 	 * case we will still switch to the new timeline and proceed replaying
> 	 * from it even though the history doesn't match what we already
> 	 * replayed. That's not good. We will likely notice at the next online
> 	 * checkpoint, as the TLI won't match what we expected, but it's
> 	 * not guaranteed. The admin needs to make sure that doesn't happen.
> 	 */

but that's a pre-existing and orthogonal issue, it can with the current 
code too if you restart the standby, so let's handle that as a separate 
patch. I'll focus on that next.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

Attachment: rescan-latest-tli-1.patch
Description: text/x-diff (4.2 KB)

Responses

pgsql-hackers by date

Next:From: Markus WannerDate: 2010-10-27 14:44:20
Subject: Re: xlog.c: WALInsertLock vs. WALWriteLock
Previous:From: Boszormenyi ZoltanDate: 2010-10-27 14:22:43
Subject: Re: Re: ECPG dynamic cursor fix for UPDATE/DELETE ... WHERE CURRENT OF :curname

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