Re: BUG #17177: Secondary fails to start after upgrade from 13.3 - Mailing list pgsql-bugs

From Kyotaro Horiguchi
Subject Re: BUG #17177: Secondary fails to start after upgrade from 13.3
Date
Msg-id 20210903.203411.1305461729557740222.horikyota.ntt@gmail.com
Whole thread Raw
In response to BUG #17177: Secondary fails to start after upgrade from 13.3  (PG Bug reporting form <noreply@postgresql.org>)
Responses Re: BUG #17177: Secondary fails to start after upgrade from 13.3
List pgsql-bugs
At Fri, 03 Sep 2021 00:31:49 +0000, PG Bug reporting form <noreply@postgresql.org> wrote in 
> ted timeline ID 2 in log segment
> 00000002000053E8000000E7, offset 4956160
> 2021-09-02 17:47:03.136 UTC [18068] (user=) (db=) (rhost=) (app=) [vxid:
> txid:0] [] LOG:  unexpected timeline ID 2 in log segment
> 00000002000053E8000000E7, offset 5890048
> 2021-09-02 17:47:03.137 UTC [18171] (user=) (db=) (rhost=) (app=) [vxid:
> txid:0] [] FATAL:  terminating walreceiver process due to administrator
> command
> Cluster is not starting.
> Tried to replace 00000002000053E8000000E7 from primary manually but it
> didn't help.
> Once downgraded postgres to 13.3, cluster started successfully in standby
> mode.
> -----------------------------------------------------
> pg_controldata output:
> -----------------------------------------------------
> pg_controldata -D /pgsql/cluster/data/
> pg_control version number:            1300
> Catalog version number:               202007201
> Database system identifier:           6942522466342357095
> Database cluster state:               in archive recovery
> pg_control last modified:             Fri 03 Sep 2021 12:28:17 AM UTC
> Latest checkpoint location:           53FC/37E028B8
> Latest checkpoint's REDO WAL file:    00000002000053FB000000FA
> Latest checkpoint's TimeLineID:       2
> Latest checkpoint's PrevTimeLineID:   2

(The file at failure is before the REDO location, but it seems because
the controldata is taken after the successful startup.)

If 0826564292156762d32c183c6708c94564fcad1c is the cause, one
possibility is that:

- You removed all WAL files before starting the standby but left
  history files alone.

- The standby has a history file for more than tli = 2 and that file
  does not contain tli = 2.

With the two above conditions, no error printed before the commit but
the same error message is printed after the commit.

Is the above conditions match your environment? If so, that would be
fixed by removing the extra history (that is, history files for TLI >
2) files.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #17179: EOF detected
Next
From: Tom Lane
Date:
Subject: Re: BUG #17178: probes.h: No such file or directory when running 'make install'