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

From Thomas Munro
Subject Re: BUG #17928: Standby fails to decode WAL on termination of primary
Date
Msg-id CA+hUKG+t8gfYBS2TRMW6rHaWUBEC1Cy+p-0pgPBx8ag8TBeoKw@mail.gmail.com
Whole thread Raw
In response to Re: BUG #17928: Standby fails to decode WAL on termination of primary  (Alexander Lakhin <exclusion@gmail.com>)
Responses Re: BUG #17928: Standby fails to decode WAL on termination of primary
List pgsql-bugs
On Fri, May 12, 2023 at 6:00 AM Alexander Lakhin <exclusion@gmail.com> wrote:
> 2023-05-11 20:19:22.248 MSK [2037134] FATAL:  invalid memory alloc request size 2021163525
> 2023-05-11 20:19:22.248 MSK [2037114] LOG:  startup process (PID 2037134) exited with exit code 1

Thanks Alexander.  Looking into this.  I think it is probably
something like: recycled standby pages are not zeroed (something we
already needed to do something about[1]), and when we read a recycled
garbage size (like your "xxxx") at the end of a page at an offset
where we don't have a full record header on one page, we skip the
ValidXLogRecordHeader() call (and always did), but the check in
allocate_recordbuf() which previously handled that "gracefully" (well,
it would try to allocate up to 1GB bogusly, but it wouldn't try to
allocate more than that and ereport) is a bit too late.  I probably
need to add an earlier not-too-big validation.  Thinking.

[1] https://www.postgresql.org/message-id/20210505010835.umylslxgq4a6rbwg@alap3.anarazel.de



pgsql-bugs by date:

Previous
From: Michael Paquier
Date:
Subject: Re: BUG #17884: gist_page_items() crashes for a non-leaf page of an index with non-key columns
Next
From: PG Bug reporting form
Date:
Subject: BUG #17931: Faild to stop PostgresSQL Service