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: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 21:53:36
Message-ID: 4A43F1E0.7010905@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-bugs
Simon Riggs wrote:
> AFAICS the problem Heikki is worried about exists 8.2+. If you stop
> recovery, edit recovery.conf to an earlier recovery target and then
> re-run recovery then it is possible that data that would not exist until
> after the (new) recovery point has made its way to disk. The code in 8.4
> does a few things to improve that but the base problem persists and
> revoking code won't change that. We should describe the issue in the
> docs and leave it at that - there is no particular reason to believe
> anybody would want to do such a thing. 

The way I've bumped into that is when playing with pg_standby:

1. Create base backup, set up standby
2. Let pg_standby catch up, so that it waits for the next segment to arrive.
3. killall -9 postmaster
4. Start standby again
5. Create trigger file, before recovery catches up again (that is,
before it reaches the point where it was before killing it)

Now that we have the "smart" mode in pg_standby, that's harder to do by
accident, but can still happen if you e.g remove a WAL file from archive.

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

In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2009-06-25 22:09:35
Subject: Re: BUG #4879: bgwriter fails to fsync the file in recovery mode
Previous:From: Simon RiggsDate: 2009-06-25 21:46:31
Subject: Re: BUG #4879: bgwriter fails to fsync the file in recoverymode

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