From: | "Fujii Masao" <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Detlef(dot)Ulherr(at)sun(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Probable problem with pg_standby |
Date: | 2008-11-04 12:50:21 |
Message-ID: | 3f0b79eb0811040450s3d126333s2593a3bd15baba58@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Nov 4, 2008 at 8:09 PM, Detlef Ulherr <Detlef(dot)Ulherr(at)sun(dot)com> wrote:
> All I did was forcing the primary in a recovery to generate a new timeline.
> The installed version was 8.3.4, but the problem is the same with earlier
> versions as well. It occurred in 8.2 also. this problem is reproducible all
> the times. For my agent code I implemented a workaround which guarantees
> that during a resilvering process the primary and the standby start at t the
> same timeline. But my feeling is that the standby should go to the same
> timeline as the primary when he receives the history file without
> disruption, and by all means it should never stop the recovery unmotivated.
> This will make a full synchronization necessary and in times of larger
> databases, this may cause major downtimes.
I agree with you only if normal archive recovery case (not specified
recovery_target_xid/time). But, in point-in-time recovery case, the standby
cannot continue to redo without stopping. DBA has to reconstruct the
standby (get new online-backup with new timeline ID, locate it on the
standby and restart recovery).
Or, we should deal with normal archive recovery and point-in-time one
separately?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2008-11-04 12:55:25 | Spurious Kerberos error messages |
Previous Message | Simon Riggs | 2008-11-04 12:19:28 | Re: Signal handling patch (v2) for Synch Rep |