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

Re: BUG #5011: Standby recovery unable to follow timeline change

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: James Bardin <jbardin(at)bu(dot)edu>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5011: Standby recovery unable to follow timeline change
Date: 2009-08-27 06:30:16
Message-ID: 4A9627F8.7070208@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-bugs
Tom Lane wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>> Tom Lane wrote:
>>> Specifically, I propose this patch instead. 
> 
>> It looks better, but leaves the door open for WAL insertions for a much
>> longer period. Particularly, there's the call to CheckpointGuts(), which
>> does a lot of things. Maybe I'm just too paranoid about keeping that
>> sanity check as tight as possible...
> 
> Well, I'd prefer to go through the LocalSetXLogInsertAllowed/
> reset LocalXLogInsertAllowed dance twice rather than have this code
> calling InitXLOGAccess directly (and unconditionally, which was
> even worse IMHO).  But I don't actually see anything wrong with
> having CheckpointGuts enabled to write WAL.  I could even see that
> being *necessary* in some future iteration of the system --- who's
> to say that a checkpoint involves adding only one WAL entry?

Yeah. maybe it's OK. There isn't anything strictly wrong about writing
WAL records at that time - we already allowed it for the rmgr cleanup
routines. CheckpointGuts is shared by recovery points, though, so any
WAL insertions in there would be conditional (like "if (in recovery)
xloginsert()").

I'll commit your patch then.

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

In response to

pgsql-bugs by date

Next:From: Magnus HaganderDate: 2009-08-27 07:00:01
Subject: Re: BUG #5008: Server Startup Problem - When server is configured for SSL
Previous:From: Greg StarkDate: 2009-08-27 04:10:41
Subject: Re: BUG #4996: postgres.exe memory consumption keeps going up

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