From: | Detlef Ulherr <Detlef(dot)Ulherr(at)Sun(dot)COM> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Probable problem with pg_standby |
Date: | 2008-11-04 13:05:31 |
Message-ID: | 4910489B.4000802@sun.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Fujii Masao wrote:
> 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,
>
>
Agreed, a point in time recovery can send the primary behind the
standby, but this should not happen with a normal archive recovery, so
separating the two cases will be a big improvement. A meaningful error
message in the log will help the poor dba, currently there is nothing in
the standby's log. It just stops the recovery.
In my case it was a normal archive recovery, and definitely no point in
time recovery.
Regards,
--
*****************************************************************************
Detlef Ulherr
Staff Engineer Tel: (++49 6103) 752-248
Availability Engineering Fax: (++49 6103) 752-167
Sun Microsystems GmbH
Amperestr. 6 mailto:detlef(dot)ulherr(at)sun(dot)com
63225 Langen http://www.sun.de/
*****************************************************************************
Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551
Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering
*****************************************************************************
From | Date | Subject | |
---|---|---|---|
Next Message | Zdenek Kotala | 2008-11-04 13:32:44 | Re: [PATCH] Extending pg_class info + more flexible TOAST chunk size |
Previous Message | Peter Eisentraut | 2008-11-04 12:55:25 | Spurious Kerberos error messages |