Re: Remaining Streaming Replication Open Items - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Remaining Streaming Replication Open Items
Date
Msg-id t2k603c8f071004060806pf763abdby2c9dd3b9a4553baf@mail.gmail.com
Whole thread Raw
In response to Re: Remaining Streaming Replication Open Items  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Remaining Streaming Replication Open Items  (Simon Riggs <simon@2ndQuadrant.com>)
Re: Remaining Streaming Replication Open Items  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
On Tue, Apr 6, 2010 at 10:36 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> Robert Haas wrote:
>> On Tue, Apr 6, 2010 at 3:09 AM, Heikki Linnakangas
>> <heikki.linnakangas@enterprisedb.com> wrote:
>>>>     * Add the GUC parameter to specify the maximum number of log file segments held in pg_xlog directory to send
tothe standby server. Which is useful to avoid disk full in the primary. 
>>> Not only to avoid disk full in primary but also to make it feasible to
>>> use streaming replication without archiving. It's a small change, we
>>> should do it.
>>
>> Do we have a working patch?
>
> No.

:-(

>>>>     * Redefine smart shutdown in standby mode?
>>> Drop. Too big a change at this point.
>>
>> We have a working patch for this - I want to commit it.  I don't think
>> it's a big change, and the current behavior is extremely pathological.
>
> Oh, ok. I didn't look at the latest patch, if it looks good to you, fine
> with me.

I'll commit it tonight.

>>>>     * 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.

...Robert


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Proposal: Add JSON support
Next
From: "David E. Wheeler"
Date:
Subject: Re: Prepared query parsing much slower in 9.0?