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

Re: BUG #4879: bgwriter fails to fsync the file in recoverymode

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #4879: bgwriter fails to fsync the file in recoverymode
Date: 2009-06-26 04:59:34
Message-ID: 1245992374.4038.353.camel@ebony.2ndQuadrant (view raw or flat)
Thread:
Lists: pgsql-bugs
On Fri, 2009-06-26 at 05:14 +0100, Simon Riggs wrote:
> On Thu, 2009-06-25 at 20:25 -0400, Tom Lane wrote:

> > What I am thinking is that instead of the hack of clearing
> > LocalRecoveryInProgress to allow the current process to write WAL,
> > we should have a separate test function WALWriteAllowed() with a
> > state variable LocalWALWriteAllowed, and the hack should set that
> > state without playing any games with LocalRecoveryInProgress.  Then
> > RecoveryInProgress() remains true during the end-of-recovery checkpoint
> > and we can condition the TruncateMultiXact and TruncateSUBTRANS calls
> > on that.  Meanwhile the various places that check RecoveryInProgress
> > to decide if WAL writing is allowed should call WALWriteAllowed()
> > instead.
> 
> No need.

Belay that. Yes, agree need for additional state, though think its more
like EndRecoveryIsComplete(). 

-- 
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support


In response to

Responses

pgsql-bugs by date

Next:From: Heikki LinnakangasDate: 2009-06-26 06:22:04
Subject: Re: BUG #4879: bgwriter fails to fsync the file in recovery mode
Previous:From: Simon RiggsDate: 2009-06-26 04:40:45
Subject: Re: BUG #4879: bgwriter fails to fsync the file in recoverymode

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