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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-bugs by date

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