On Tue, Apr 13, 2010 at 11:49 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> Robert Haas wrote:
>> On Tue, Apr 6, 2010 at 10:36 AM, Heikki Linnakangas
>> <heikki.linnakangas@enterprisedb.com> wrote:
>>> Robert Haas wrote:
>>>>>> * If standby_mode is enabled, and neither primary_conninfo nor restore_command are set, the standby would
getstuck.
>>>>> It's not really stuck, it will replay any WAL files you drop into
>>>>> pg_xlog. I concur with Robert Haas though that it shouldn't print the
>>>>> message to the log every few seconds. It should print a message the
>>>>> first time it hits the end of WAL, but subsequent messages should be
>>>>> suppressed until some progress has been made.
>>>> Any idea how to implement this?
>>> I'll take a look. It shouldn't be too hard.
>>
>> The tricky part, I believe, is that there's more than one message that
>> can potentially be emitted, and you don't want ANY of them to repeat
>> every 2 s, so some thought needs to be given to where to hook in the
>> logic.
>
> We have the emode_for_corrupt_record() function that's used in all the
> errors that indicate a corrupt WAL record, that's a perfect place to
> hook this into. See attached patch.
The test for elog == LOG seems a bit fragile to me - why that
specifically? Maybe elog < PANIC? elog > DEBUG1? Both?
But it seems basically sensible to me.
...Robert
