On Wed, Mar 26, 2014 at 9:45 PM, Peter Geoghegan <pg@heroku.com> wrote:
> On Wed, Nov 27, 2013 at 9:10 AM, Noah Misch <noah@leadboat.com> wrote:
>> 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.
>
> Attached patch silences the "Invalid read of size n" complaints of
> Valgrind. I agree with your general thoughts around backpatching. Note
> that the patch addresses a distinct complaint from Kevin's, as
> Valgrind doesn't take issue with the invalid reads past the end of
> spgxlogPickSplit variables on the stack.
Is the needless zeroing this patch introduces apt to cause a
performance problem?
This function is actually pretty wacky. If we're stuffing bytes with
undefined contents into the WAL record, maybe the answer isn't to
force the contents of those bytes to be defined, but rather to elide
them from the WAL record.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company