Re: BUG #17177: Secondary fails to start after upgrade from 13.3

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: abartash(at)xmatters(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17177: Secondary fails to start after upgrade from 13.3
Date: 2021-09-03 11:34:11
Message-ID: 20210903.203411.1305461729557740222.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

At Fri, 03 Sep 2021 00:31:49 +0000, PG Bug reporting form <noreply(at)postgresql(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2021-09-03 13:23:39 Re: BUG #17178: probes.h: No such file or directory when running 'make install'
Previous Message PG Bug reporting form 2021-09-03 05:47:15 BUG #17179: EOF detected