Re: BUG #15943: Valgrind-detected error in SlruPhysicalWritePage - Mailing list pgsql-bugs

From Andres Freund
Subject Re: BUG #15943: Valgrind-detected error in SlruPhysicalWritePage
Date
Msg-id BE3C7FA7-37CB-4058-BED1-EFFEA6E6249D@anarazel.de
Whole thread Raw
In response to Re: BUG #15943: Valgrind-detected error in SlruPhysicalWritePage  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
Hi,

On August 8, 2019 2:41:42 PM EDT, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>Andres Freund <andres@anarazel.de> writes:
>> Seems there's no reason to not zero initialize memory here? But
>perhaps just by initializing the stack variable?
>
>I think all we need here is another suppression in
>src/tools/valgrind.supp.  We have not insisted on zeroing
>pad bytes that get sent to disk in the places already
>enumerated in valgrind.supp, so why would we apply a
>different rule to async.c?

Well, with a lot of the other case there's a lot of sources for such uninitialized data. Here there probably is just
one?If it weren't such a game of whack a mole, I'd even consider properly initializing the other places. And
initializingthe stack data here ought to be cheap in this case? 

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #15943: Valgrind-detected error in SlruPhysicalWritePage
Next
From: Michael Paquier
Date:
Subject: Re: Error in COPY command with files over 1GB