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

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

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndQuadrant(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 recovery mode
Date: 2009-06-25 20:35:11
Message-ID: 4A43DF7F.3000205@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:
>>> Actually, what in the world is the purpose of that code at all?
> 
>> Huh? The only other place where we advance minimum recovery point is
>> CreateRestartPoint() when we skip the restartpoint. The
>> UpdateMinRecoveryPoint() call in XLogFlush() is what we rely on.
> 
> I would like an explanation of why minimum recovery point needs to
> be advanced at all.  If there's any use for it, it is surely part
> of functionality that is not there in 8.4.

It gives protection against starting up the database too early. It stops
the database from starting up if you stop recovery, and move recovery
target backwards or delete WAL files from pg_xlog, in a way that's not
safe. Of course, that's a case of "don't do that!", but it's a mistake
you can make when trying to manually recover to a given point in time.
Or if your recovery scripts are broken.

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

In response to

Responses

pgsql-bugs by date

Next:From: Dave PageDate: 2009-06-25 20:36:11
Subject: Re: BUG #4882: One-click installer crashes with certain service account passwords
Previous:From: Simon RiggsDate: 2009-06-25 20:21:06
Subject: Re: BUG #4879: bgwriter fails to fsync the file in recoverymode

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