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

From Tom Lane
Subject Re: BUG #4879: bgwriter fails to fsync the file in recovery mode
Date
Msg-id 6010.1246027237@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #4879: bgwriter fails to fsync the file in recovery mode  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-bugs
Heikki Linnakangas <heikki.linnakangas@enterprisedb.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

pgsql-bugs by date:

Previous
From: "Alexey Bashtanov"
Date:
Subject: BUG #4887: inclusion operator (@>) on tsqeries behaves not conforming to documentation
Next
From: Tom Lane
Date:
Subject: Re: BUG #4879: bgwriter fails to fsync the file in recovery mode