pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Alexander Lakhin <exclusion@gmail.com>
Cc: Sergei Kornilov <sk@zsrv.org>
Cc: Noah Misch <noah@leadboat.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org, Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: pgbf@twiska.com
Subject: Re: BUG #17928: Standby fails to decode WAL on termination of primary
Date: Mon, 25 Sep 2023 01:29:26 -0400
Message-ID: <90044.1695619766@sss.pgh.pa.us> (raw)
In-Reply-To: <CA+hUKGLCkTT7zYjzOxuLGahBdQ=McF=z5ZvrjSOnW4EDhVjT-g@mail.gmail.com>
References: <ZQpCG5QanJQXNVH-@paquier.xyz>
	<CA+hUKGKJx=S77ttAtJ_iA=oBGUf2VTnfUp-gtJEhdXCbmdkoAA@mail.gmail.com>
	<ZQ0R4kz3gN6bqS1N@paquier.xyz>
	<CA+hUKGK1+3rj3c7L9HPCc8HajTVmkTx1CEkU5=rqgV3b4OvWeQ@mail.gmail.com>
	<ZQ4r1vHcryBsSi_V@paquier.xyz>
	<CA+hUKGKs=yj55ejAwuUJQuURU=uKjYgRqEQcCi1GrP2+=jUgNQ@mail.gmail.com>
	<ZQ5tIoarrcwAlbVZ@paquier.xyz>
	<CA+hUKGJf3Hhb2MB88-rW2di2H9XT0xr6-hd6ZjGEwdJs3A=b+Q@mail.gmail.com>
	<ZQ9zf1QO8CP4TZRO@paquier.xyz>
	<CA+hUKGKo5O_f8aBDoEMkxHmuWdFfmPPo6wL4q85b_0PDuHwZEA@mail.gmail.com>
	<ZRDNNf8Etlvuo48a@paquier.xyz>
	<CA+hUKG+cXwfAk0dEbD5CZ76p1uADGywuvb6_N4Uhziek54FZHg@mail.gmail.com>
	<64446.1695611228@sss.pgh.pa.us>
	<CA+hUKGLF7NS-eUUuSaRoU7XvcTJDztf9wKXGo3GmjGnUrr8EzQ@mail.gmail.com>
	<86521.1695617949@sss.pgh.pa.us>
	<CA+hUKGLCkTT7zYjzOxuLGahBdQ=McF=z5ZvrjSOnW4EDhVjT-g@mail.gmail.com>

Thomas Munro <thomas.munro@gmail.com> writes:
> If you happened to run into zeroes where an xl_tot_len is wanted right
> at the end of a page (or any value not big enough to get you to the
> next page), we'll fall through to the single-page branch, and then go
> directly to the CRC check, but then ValidXLogRecord() subtracts
> SizeOfXLogRecord and gets a crazy big length.  The CRC implementation
> routines on modern computers happened to use pointer arithmetic that
> terminates immediately without accessing any memory, which is why
> nothing was obviously wrong on most systems.  The _sb8.c
> implementation for older ARM, MIPS etc use a length-based loop, and
> read off into deep space.

Ah-hah.  Maybe there should be an Assert in the modern CRC code path
that detects the bogus arguments?

> Draft patch attached, including a new test for 039_end_of_wal.pl that
> fails on all systems without the above code.

Both the 009 and 039 tests pass on mamba with this patch.  I did
not read the code, but testing-wise it seems good.

			regards, tom lane





view thread (86+ messages)  latest in thread

Message-ID: <90044.1695619766@sss.pgh.pa.us>
Permalink:  ../90044.1695619766@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/90044.1695619766@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: tgl@sss.pgh.pa.us, thomas.munro@gmail.com, michael@paquier.xyz, exclusion@gmail.com, sk@zsrv.org, noah@leadboat.com, horikyota.ntt@gmail.com, masao.fujii@oss.nttdata.com, pgbf@twiska.com
  Subject: Re: BUG #17928: Standby fails to decode WAL on termination of primary
  In-Reply-To: <90044.1695619766@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox