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: