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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
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 21:17:48
Message-ID: 5644.1245964668@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Simon Riggs 2009-06-25 21:24:43 Re: BUG #4879: bgwriter fails to fsync the file in recovery mode
Previous Message Tom Lane 2009-06-25 21:11:02 Re: BUG #4879: bgwriter fails to fsync the file in recovery mode