From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Remaining Streaming Replication Open Items |
Date: | 2010-04-13 15:49:12 |
Message-ID: | 4BC49278.2040400@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
only-complain-on-first-time-a-record-is-corrupt-1.patch | text/x-diff | 11.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2010-04-13 15:56:00 | Re: Streaming replication and a disk full in primary |
Previous Message | Jaime Casanova | 2010-04-13 15:41:08 | hash indexes and HS was:(Re: [HACKERS] testing hot standby) |