2010/1/26 Heikki Linnakangas <heikki.linnakan...@enterprisedb.com>: > Magnus Hagander wrote: >> I think there are definite use-cases for pg_standby as well, even when >> we have SR. SR requires you to have a reasonably reliable network >> connection that lets you do an arbitrary TCP connection. There are a >> lot of scenarios that could still use the >> "here's-a-file-you-choose-how-to-get-it-over-to-the-other-end" style >> transfer, and that don't necessarily care that there is a longer >> delay. > > With the changes to the retry-logic that were discussed (see > http://archives.postgresql.org/message-id/4b5758ed.1060...@enterprisedb.com, > I intend to commit that tomorrow), if standby_mode=on, the server will > keep retrying to restore the next segment using restore_command until > it's found, or the trigger file is found. > > *That* makes pg_standby obsolete, not streaming replication per se. > Setting standby_mode=on, with a valid restore_command using e.g 'cp' and > no connection info for walreceiver is more or less the same as using > pg_standby.
Ah, ok, missed that. So it basically folds pg_standby into the backend. In *that* case, I can see how pg_standby would be obsolete. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
