Re: Remaining Streaming Replication Open Items

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-06 12:08:26
Message-ID: k2i603c8f071004060508pb84840cby94f9f64b9a131d19@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote my previous email before reading this.

On Tue, Apr 6, 2010 at 3:09 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)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 the 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?

>>     * pg_xlogfile_name(pg_last_xlog_receive/replay_location()) might report the wrong name. Because a backend cannot know the 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 making SR 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-04-06 12:09:37 Re: Re: [COMMITTERS] pgsql: Check compulsory parameters in recovery.conf in standby_mode, per
Previous Message Fujii Masao 2010-04-06 12:05:40 Re: pending patch: Re: Streaming replication and pg_xlogfile_name()