Re: Remaining Streaming Replication Open Items

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

In response to

Responses

Browse pgsql-hackers by date

  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)