From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Remaining Streaming Replication Open Items |
Date: | 2010-04-14 00:33:31 |
Message-ID: | u2m603c8f071004131733vbda495d1rb77979416ecb1195@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Apr 13, 2010 at 11:49 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> Robert Haas wrote:
>> On Tue, Apr 6, 2010 at 10:36 AM, Heikki Linnakangas
>> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>>> Robert Haas wrote:
>>>>>> * If standby_mode is enabled, and neither primary_conninfo nor restore_command are set, the standby would get stuck.
>>>>> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Erik Rijkers | 2010-04-14 00:34:09 | testing HS/SR - invalid magic number |
Previous Message | Robert Haas | 2010-04-14 00:25:20 | Re: Autonomous transaction |