Re: BUG #4879: bgwriter fails to fsync the file in recovery mode - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #4879: bgwriter fails to fsync the file in recovery mode
Date
Msg-id 5644.1245964668@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #4879: bgwriter fails to fsync the file in recovery mode  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: BUG #4879: bgwriter fails to fsync the file in recovery mode  (Simon Riggs <simon@2ndQuadrant.com>)
Re: BUG #4879: bgwriter fails to fsync the file in recovery mode  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-bugs
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> We do store the minimum recovery point required by the base backup in
> control file, but it's not advanced once the recovery starts. So if you
> start recovery, starting from say 123, let it progress to location 456,
> kill recovery and start it again, but only let it go up to 300, you end
> up with a corrupt database.

I don't believe that you have the ability to do that.  Once the recovery
process is launched, the user does not have the ability to control where
the WAL scan proceeds from.  Or at least that's how it used to work, and
if someone has tried to change it, it's broken for exactly this reason.

The behavior you seem to have in mind would be completely disastrous
from a performance standpoint, as we'd be writing and fsyncing
pg_control constantly during a recovery.  I wouldn't consider that a
good idea from a reliability standpoint either --- the more writes to
pg_control, the more risk of fatal corruption of that file.

This is sounding more and more like something that needs to be reverted.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #4879: bgwriter fails to fsync the file in recovery mode
Next
From: Simon Riggs
Date:
Subject: Re: BUG #4879: bgwriter fails to fsync the file in recovery mode