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