| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, 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:50:24 |
| Message-ID: | 27958.1245959424@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2009-06-25 19:57:09 | Re: BUG #4879: bgwriter fails to fsync the file in recovery mode |
| Previous Message | Tom Lane | 2009-06-25 19:38:53 | Re: BUG #4879: bgwriter fails to fsync the file in recovery mode |