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

From Robert Haas
Subject Re: Remaining Streaming Replication Open Items
Date
Msg-id k2i603c8f071004060508pb84840cby94f9f64b9a131d19@mail.gmail.com
Whole thread Raw
In response to Remaining Streaming Replication Open Items  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Remaining Streaming Replication Open Items
List pgsql-hackers
I wrote my previous email before reading this.

On Tue, Apr 6, 2010 at 3:09 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> I triaged the list of open items on the Streaming Replication wiki page.
> I propose that we drop the ones I've marked as Drop below, and move the
> remaining items to the main Open Items page for better visibility. And
> of course try to resolve them as quickly as possible.
>
>>     *  Walsender and dblink are not interruptible on win32. - related thread
>
> I'd actually be happy to just leave it for 9.0, but it seems like
> consensus has been reached on how to fix it, and Fujii is working on a
> patch, so let's follow that through.

Agree.

>>     * Add the GUC parameter to specify the maximum number of log file segments held in pg_xlog directory to send to
thestandby 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?

>>     * pg_xlogfile_name(pg_last_xlog_receive/replay_location()) might report the wrong name. Because a backend cannot
knowthe actual timeline which is related to the location. 
>
> Drop. It's not clear which timeline those functions should return in
> boundary cases, when replaying records from a log file where the
> timeline-switch occurs.

Agree.

>>     * The documentation needs to be improved.
>
> I've done as much as I can on my own, what we need now is feedback on
> what needs to be improved. So I'd like to drop this, but let's add new
> more specific items about what needs to be improved, as people speak up.

Agree.  It's hard to think of this as a beta-blocker without more
specific feedback.

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

>>     * Quotes can't be escaped in recovery.conf
>
> Under discussion. Not specific to streaming replication, and it's a
> pre-existing issue, but should be fixed IMHO.

Fine with me.

>>     * Change the "standby mode" name.
>
> Bikeshedding without consensus. I like the "standby mode" the best as
> discussed on that thread, better than any of the proposed alternatives.
> Drop this item.

OK.

>>     * Fix things so that any such variables inherited from the server environment are intentionally *NOT* used for
makingSR connections. 
>
> Drop. Besides, we have the same problem with dblink, and I don't recall
> anyone complaining.

Agree.  I think that whole issue is bikeshedding.

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

>>     * Remove the unnecessary section about HS from recovery.conf.sample
>
> Yeah, let's do it.

Don't care.

>>     * The replication connections consume superuser_reserved_connections slots.
>
> I'd still like to change this slightly, per my suggestion on that
> thread, but I don't feel strongly about it. It doesn't seem like a very
> big change to me, but Tom felt otherwise.

Agree, we should fix it.

>>     * Add missing description about WAL-logging.
>
> Small documentation change. Needs to be done I guess.

No strong feelings.

...Robert


pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: pending patch: Re: Streaming replication and pg_xlogfile_name()
Next
From: Robert Haas
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Check compulsory parameters in recovery.conf in standby_mode, per