We are using 9.1.,
We have a set up like a master and 2 standby servers. M -- > S1,S2 . Both
standby S1 and S2 share the same archive. Master will have an Virtual IP.
Both stand by servers will be replicated using this virtual ip.
Assume the master fails,using our heart beat mechanism Virtual IP
On Mon, Oct 3, 2011 at 3:18 PM, senthilnathan wrote:
> Whether this feature is available in version 9.1.0. ??
Yes, it's available in 9.1.x.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers
Whether this feature is available in version 9.1.0. ??
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Tracking-latest-timeline-in-standby-mode-tp3238829p4863900.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
--
Sent via pgsql-hackers maili
On 07.03.2011 14:35, Fujii Masao wrote:
Comments:
+ if (!list_member_int(expectedTLIs,
+(int)
recoveryTargetTLI))
+ ereport(LOG,
+ (errmsg("new timeline %u is not a
On Mon, Mar 7, 2011 at 9:06 PM, Magnus Hagander wrote:
>> I dropped the ball on this one, but now that we have pg_basebackup and
>> "pg_ctl promote" which make it easy to set up a standby and failover, I
>> think we should still do this in 9.1. Otherwise you need a restart to have a
>> 2nd standby
On Mon, Mar 7, 2011 at 11:52, Heikki Linnakangas
wrote:
> On 08.02.2011 06:27, Robert Haas wrote:
>>
>> On Mon, Jan 24, 2011 at 2:00 AM, Fujii Masao
>> wrote:
>>>
>>> On Wed, Jan 5, 2011 at 5:08 AM, Heikki Linnakangas
>>> wrote:
I finally got around to look at this. I wrote a patch to
On 08.02.2011 06:27, Robert Haas wrote:
On Mon, Jan 24, 2011 at 2:00 AM, Fujii Masao wrote:
On Wed, Jan 5, 2011 at 5:08 AM, Heikki Linnakangas
wrote:
I finally got around to look at this. I wrote a patch to validate that the
TLI on xlog page header matches ThisTimeLineID during recovery, and
On Mon, Jan 24, 2011 at 2:00 AM, Fujii Masao wrote:
> On Wed, Jan 5, 2011 at 5:08 AM, Heikki Linnakangas
> wrote:
>> I finally got around to look at this. I wrote a patch to validate that the
>> TLI on xlog page header matches ThisTimeLineID during recovery, and noticed
>> quickly in testing that
On Wed, Jan 5, 2011 at 5:08 AM, Heikki Linnakangas
wrote:
> I finally got around to look at this. I wrote a patch to validate that the
> TLI on xlog page header matches ThisTimeLineID during recovery, and noticed
> quickly in testing that it doesn't catch all the cases I'd like to catch
> :-(.
Th
On 02.11.2010 07:15, Fujii Masao wrote:
On Mon, Nov 1, 2010 at 8:32 PM, Heikki Linnakangas
wrote:
Yeah, that's one approach. Another is to validate the TLI in the xlog page
header, it should always match the current timeline we're on. That would
feel more robust to me.
Yeah, that seems bette
On 02.11.2010 07:15, Fujii Masao wrote:
On Mon, Nov 1, 2010 at 8:32 PM, Heikki Linnakangas
wrote:
Yeah, that's one approach. Another is to validate the TLI in the xlog page
header, it should always match the current timeline we're on. That would
feel more robust to me.
Yeah, that seems bette
On Mon, Nov 1, 2010 at 8:32 PM, Heikki Linnakangas
wrote:
> Yeah, that's one approach. Another is to validate the TLI in the xlog page
> header, it should always match the current timeline we're on. That would
> feel more robust to me.
Yeah, that seems better.
> We're a bit fuzzy about what TLI
On 01.11.2010 12:32, Fujii Masao wrote:
A related issue is that we should have a check for the issue I also
mentioned in the comments:
/*
* If the current timeline is not part of the history of the
* new timeline, we cannot proceed to it.
*
* XXX This
On Wed, Oct 27, 2010 at 11:42 PM, Heikki Linnakangas
wrote:
> At the moment, when you specify recovery_target_timeline='latest', we scan
> for the latest timeline at the beginning of recovery, and pick that as the
> target. If new timelines appear during recovery, we stick to the target
> chosen i
14 matches
Mail list logo
