| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Alexander Lakhin <exclusion(at)gmail(dot)com>, Sergei Kornilov <sk(at)zsrv(dot)org>, Noah Misch <noah(at)leadboat(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
| Subject: | Re: BUG #17928: Standby fails to decode WAL on termination of primary |
| Date: | 2023-09-22 03:11:54 |
| Message-ID: | CA+hUKGKJx=S77ttAtJ_iA=oBGUf2VTnfUp-gtJEhdXCbmdkoAA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
A thought: commit 8fcb32db prevented us from logging messages that are
too big to be decoded, but it wasn't back-patched. I think that means
that in older branches, there is a behaviour change unrelated to the
"garbage bytes" problem discussed in this thread, and separate also
from the out-of-memory problem. If someone generates a record too big
to decode, say with pg_logical_emit_message(), we will fail
differently. Before this patch set, we'd bogusly detect end-of-WAL,
and after this patch we'd fail to palloc and recovery would bogusly
fail. Which outcome is more bogus is hard to answer, and clearly we
should prevent it upstream, but didn't for technical reasons. Do you
agree that that is a separate topic that doesn't prevent us from
committing this fix?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2023-09-22 04:02:42 | Re: BUG #17928: Standby fails to decode WAL on termination of primary |
| Previous Message | Tom Lane | 2023-09-22 02:08:18 | Re: BUG #18124: PG16 release note document bug in "Add build option to allow testing of small WAL segment sizes" |