Re: recovery_connections cannot start (was Re: master in standby mode croaks)
От | Robert Haas |
---|---|
Тема | Re: recovery_connections cannot start (was Re: master in standby mode croaks) |
Дата | |
Msg-id | g2n603c8f071004231205m9fabe751r38d8940f31b86fc9@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: recovery_connections cannot start (was Re: master in standby mode croaks) ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: recovery_connections cannot start (was Re: master in
standby mode croaks)
|
Список | pgsql-hackers |
On Fri, Apr 23, 2010 at 2:43 PM, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> As a concrete example, there is nothing logically wrong with >> driving a hot standby slave from WAL records shipped via old-style >> pg_standby. Or how about wanting to turn off recovery_connections >> temporarily, but not wanting the archived WAL to be unable to >> support HS? > > As one more concrete example, we are likely to find SR beneficial if > it can feed into a warm standby, but only if we can also do > traditional WAL file archiving from the same source at the same > time. The extra logging for HS would be useless for us in any > event. > > +1 for *not* tying WAL contents to the transport mechanism. OK. Well, it's a shame we didn't get this settled last week when I first brought it up, but it's not too late to try to straighten it out if we have a consensus behind changing it, which it's starting to sound like we do. ...Robert
В списке pgsql-hackers по дате отправления: