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  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Dimitri Fontaine
Дата:
Сообщение: Re: Dividing progress/debug information in pg_standby, and stat before copy
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Dividing progress/debug information in pg_standby, and stat before copy