| 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-26 14:40:37 |
| Message-ID: | 6010.1246027237@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:
> Tom Lane wrote:
>> I observe that the substantial amount of care we have taken over
>> XLogFlush's handling of bad-input-LSN scenarios has been completely
>> destroyed by the UpdateMinRecoveryPoint patch, which will fail
>> disastrously (leaving the database unstartable/unrecoverable) if a
>> bogusly large LSN is encountered during recovery.
> Note that we don't update minRecoveryPoint to the LSN from the data
> page, but to the LSN of the last replayed WAL record. A warning similar
> to that at the end of XLogFlush() would be a good idea though, if the
> data page LSN is greater.
Ah, roger, so actually we can make this *better* than it was before.
The special case in XLogFlush is no longer needed, because the case
in which we formerly wished to use WARNING is now diverted to
UpdateMinRecoveryPoint. But the latter ought to handle the situation
explicitly.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-06-26 14:49:16 | Re: BUG #4879: bgwriter fails to fsync the file in recovery mode |
| Previous Message | Alexey Bashtanov | 2009-06-26 12:54:22 | BUG #4887: inclusion operator (@>) on tsqeries behaves not conforming to documentation |