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

Re: Getting to 8.3 beta1

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Getting to 8.3 beta1
Date: 2007-09-27 16:26:58
Message-ID: 10423.1190910418@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
I wrote:
> Looking back at your original discussion of the bug,
> http://archives.postgresql.org/pgsql-hackers/2007-06/msg00234.php
> I'm wondering why you chose option #3 rather than option #4?
> I still find the proposed patch a bit crufty.

In particular, it seems like a patch per #4 would be a one-liner:

*** src/backend/access/transam/xlog.c.orig	Wed Sep 26 18:36:30 2007
--- src/backend/access/transam/xlog.c	Thu Sep 27 12:20:56 2007
***************
*** 5092,5101 ****
  	 *
  	 * If we stopped short of the end of WAL during recovery, then we are
  	 * generating a new timeline and must assign it a unique new ID.
  	 * Otherwise, we can just extend the timeline we were in when we ran out
  	 * of WAL.
  	 */
! 	if (needNewTimeLine)
  	{
  		ThisTimeLineID = findNewestTimeLine(recoveryTargetTLI) + 1;
  		ereport(LOG,
--- 5092,5103 ----
  	 *
  	 * If we stopped short of the end of WAL during recovery, then we are
  	 * generating a new timeline and must assign it a unique new ID.
+ 	 * We also force a new timeline when recovering from an archive, to avoid
+ 	 * problems with trying to overwrite existing archived segments.
  	 * Otherwise, we can just extend the timeline we were in when we ran out
  	 * of WAL.
  	 */
! 	if (needNewTimeLine || (InArchiveRecovery && XLogArchivingActive()))
  	{
  		ThisTimeLineID = findNewestTimeLine(recoveryTargetTLI) + 1;
  		ereport(LOG,

though I admit I've not tested this.  The comments in
exitArchiveRecovery probably need adjustment too --- re-reading them,
it seems obvious that the current approach is broken by design, because
it *must* lead to an attempt to overwrite a previously archived version
of the last segment.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2007-09-27 16:32:05
Subject: Re: Getting to 8.3 beta1
Previous:From: Tom LaneDate: 2007-09-27 16:07:36
Subject: Re: Getting to 8.3 beta1

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