Re: BUG #17928: Standby fails to decode WAL on termination of primary - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #17928: Standby fails to decode WAL on termination of primary
Date
Msg-id 90044.1695619766@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #17928: Standby fails to decode WAL on termination of primary  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: BUG #17928: Standby fails to decode WAL on termination of primary
List pgsql-bugs
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



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #17928: Standby fails to decode WAL on termination of primary
Next
From: Michael Paquier
Date:
Subject: Re: BUG #17928: Standby fails to decode WAL on termination of primary