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

From Heikki Linnakangas
Subject Re: BUG #4879: bgwriter fails to fsync the file in recovery mode
Date
Msg-id 4A43D695.90404@enterprisedb.com
Whole thread Raw
In response to Re: BUG #4879: bgwriter fails to fsync the file in recovery mode  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #4879: bgwriter fails to fsync the file in recovery mode  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
Tom Lane wrote:
> I wrote:
>> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>>> Hmm, I see another small issue. We now keep track of the "minimum
>>> recovery point". Whenever a data page is flushed, we set minimum
>>> recovery point to the LSN of the page in XLogFlush(), instead of
>>> fsyncing WAL like we do in normal operation.
>
>> We would want the end-of-recovery checkpoint to act like it's not in
>> recovery anymore for this purpose, no?
>
> Actually, what in the world is the purpose of that code at all?
> I can't see a case where it would trigger that wouldn't be a result
> of data corruption rather than a real need to advance the min restart
> point.

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.

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

pgsql-bugs by date:

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