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

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

Tom Lane wrote:
> I wrote:
>> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2009-06-25 20:00:44 Re: BUG #4879: bgwriter fails to fsync the file in recovery mode
Previous Message Tom Lane 2009-06-25 19:50:24 Re: BUG #4879: bgwriter fails to fsync the file in recovery mode