From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: recovery_connections cannot start (was Re: master in standby mode croaks) |
Date: | 2010-04-23 19:05:06 |
Message-ID: | g2n603c8f071004231205m9fabe751r38d8940f31b86fc9@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Apr 23, 2010 at 2:43 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2010-04-23 19:11:43 | Re: recovery_connections cannot start (was Re: master in standby mode croaks) |
Previous Message | Simon Riggs | 2010-04-23 18:55:48 | Re: recovery_connections cannot start (was Re: master in standby mode croaks) |