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
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 |