Re: Dividing progress/debug information in pg_standby, and stat before copy
От | Simon Riggs |
---|---|
Тема | Re: Dividing progress/debug information in pg_standby, and stat before copy |
Дата | |
Msg-id | 1264503304.24669.4902.camel@ebony обсуждение исходный текст |
Ответ на | Re: Dividing progress/debug information in pg_standby, and stat before copy (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Dividing progress/debug information in pg_standby,
and stat before copy
|
Список | pgsql-hackers |
On Tue, 2010-01-26 at 12:12 +0200, Heikki Linnakangas wrote: > 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. It could be, but that is not what you've mentioned before and I don't think its that simple. If no connection info is set we use existing defaults and attempt that. ISTM there is no way to set connection info to be "unset", or to request that it doesn't keep continually retrying. Currently, we had presumed that standby_mode = off would be the same as Warm Standby replication, using pg_standby or other. pg_standby checks file size before returning. If you just use "cp" as suggested then it would fail because the copy would start before the file is ready to be copied. I'm not against including pg_standby features in backend, as long as you provide *all* of the features and test that mode of operation. Even so, you're still likely to remove something someone currently thinks important. Please don't be so quick to slam the door on previous ways of working. When sync rep fails, I would not wish to find that the parachute has been removed to keep the balloon tidy or that the hole at the top has been widened to improve the view. That isn't an argument to spend further time on pg_standby, but if people feel its important and they have time, I would not stop them. -- Simon Riggs www.2ndQuadrant.com
В списке pgsql-hackers по дате отправления: