Noah Misch <noah@leadboat.com> wrote:
> (Kevin, I saw no attachment.)
Apologies. Trying again.
> The threat is that rounding the read size up to the next MAXALIGN
> would cross into an unreadable memory page, resulting in a
> SIGSEGV. Every palloc chunk has MAXALIGN'd size under the hood,
> so the excess read of "toDelete" cannot cause a SIGSEGV. For a
> stack variable, it depends on the ABI. I'm not aware of an ABI
> where the four bytes past the end of this stack variable could be
> unreadable, which is not to claim I'm well-read on the topic. We
> should fix this in due course on code hygiene grounds, but I
> would not back-patch it.
If you're sure. I hadn't worked through the code, but had two
concerns (neither of which was about a SEGSEGV):
(1) That multiple MAXALIGNs of shorter values could push the
structure into overlap with the next thing on the stack, allowing
one or the other to get stepped on.
(2) That the CRC calculation might picking up uninitialized data
which was not actually going to match what was used during
recovery, leading to "end of recovery" on replay.
If you are confident that neither of these is a real risk, I'll
relax about this.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
