Re: Dividing progress/debug information in pg_standby, and stat before copy

2010/1/26 Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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.1060703@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/