Re: pg_waldump error message fix

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: bossartn(at)amazon(dot)com
Cc: michael(at)paquier(dot)xyz, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_waldump error message fix
Date: 2020-12-14 02:34:51
Message-ID: 20201214.113451.2231140800354158395.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> At Fri, 11 Dec 2020 19:27:31 +0000, "Bossart, Nathan" <bossartn(at)amazon(dot)com> wrote in
> > I looked through all the calls to report_invalid_record() in
> > xlogreader.c and noticed that all but a few in
> > XLogReaderValidatePageHeader() already report an LSN. Of the calls in
> > XLogReaderValidatePageHeader() that don't report an LSN, it looks like
> > most still report a position, and the remaining ones are for "WAL file
> > is from different database system...," which IIUC generally happens on
> > the first page of the segment.

Apart from this issue, while checking that, I noticed that if server
starts having WALs from a server of a different systemid, the server
stops with obscure messages.

> LOG: database system was shut down at 2020-12-14 10:36:02 JST
> LOG: invalid primary checkpoint record
> PANIC: could not locate a valid checkpoint record

The cause is XLogPageRead erases the error message set by
XLogReaderValidatePageHeader(). As the comment just above says, this
is required to continue replication under a certain situation. The
code is aiming to allow continue replication when the first half of a
continued record has been removed on the primary so we don't need to
do the amendment unless we're in standby mode. If we let the savior
code only while StandbyMode, we would have the correct error message.

> JST LOG: database system was shut down at 2020-12-14 10:36:02 JST
> LOG: WAL file is from different database system: WAL file database system identifier is 6905923817995618754, pg_control database system identifier is 6905924227171453468
> JST LOG: invalid primary checkpoint record
> JST PANIC: could not locate a valid checkpoint record

I confirmed 0668719801 still works under the intended context using
the steps shown in [1].

[1]: https://www.postgresql.org/message-id/flat/CACJqAM3xVz0JY1XFDKPP%2BJoJAjoGx%3DGNuOAshEDWCext7BFvCQ%40mail.gmail.com

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

Attachment Content-Type Size
0001-Don-t-cancel-invalid-page-header-error-in-unwanted-s.patch text/x-patch 1.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message k.jamison@fujitsu.com 2020-12-14 03:00:12 RE: [Patch] Optimize dropping of relation buffers using dlist
Previous Message Kyotaro Horiguchi 2020-12-14 01:26:01 Re: pg_waldump error message fix