Re: BUG #17928: Standby fails to decode WAL on termination of primary

Noah Misch <noah@leadboat.com>

From: Noah Misch <noah@leadboat.com>

To: Thomas Munro <thomas.munro@gmail.com>

Cc: Alexander Lakhin <exclusion@gmail.com>, pgsql-bugs@lists.postgresql.org

Date: 2023-07-10T20:00:12Z

Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Correct assertion and comments about XLogRecordMaxSize.
- e1f95ec8cf6e 17.0 landed
Fix edge-case for xl_tot_len broken by bae868ca.
- bde2f1847f51 12.17 landed
- 45d1fe8b53d4 13.13 landed
- 3d413c5a76fa 14.10 landed
- 99d334a187ae 15.5 landed
- 10d0591ea227 16.1 landed
- becfbdd6c1c9 17.0 landed
Don't use Perl pack('Q') in 039_end_of_wal.pl.
- 82314dbfca7f 12.17 landed
- 07896f468f23 13.13 landed
- afa504ba2f5d 14.10 landed
- 21b4c3ca0b22 15.5 landed
- cc58607b019a 16.1 landed
- 91b0e85aa0ad 17.0 landed
Don't trust unvalidated xl_tot_len.
- e8f3c0687116 12.17 landed
- 6606c57162cb 13.13 landed
- 3ce3b53d76a3 14.10 landed
- f4d152edd8f3 15.5 landed
- ce497f648e2d 16.1 landed
- bae868caf222 17.0 landed
Make recovery report error message when invalid page header is found.
- 7b03d3a3ba45 12.17 landed
- 5dc093eacef1 13.13 landed
- 2f13e8d9ec28 14.10 landed
Add more protections in WAL record APIs against overflows
- 8fcb32db98ed 16.0 cited

Attachments

xl_tot_len-validate-v1.patch (text/plain) patch v1

On Mon, May 15, 2023 at 03:38:17PM +1200, Thomas Munro wrote:
> 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.

I agree about an earlier not-too-big validation.  Like the attached?  I
haven't tested it with Alexander's recipe or pondered it thoroughly.

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

Regarding [1], is it still worth zeroing recycled pages on standbys and/or
reading the whole header before allocating xl_tot_len?  (Are there benefits
other than avoiding a 1G backend allocation or 4G frontend allocation, or is
that benefit worth the cycles?)