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. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
