Shachar Shemesh <psql@shemesh.biz> writes:
> Tom Lane wrote:
>> The original pad bytes may be fairly far removed from the point of the
>> error ... an example is that I was able to make one XLogInsert complaint
>> go away by changing palloc to palloc0 at tupdesc.c line 413 (in
>> TupleDescInitEntry), which is several memcpy's removed from the data
>> that gets passed to XLogInsert.
> If I understand this correctly, that was a real bug there, wasn't it?
No, just a complete waste of time. The "uninitialized" data is just
struct padding, and it matters not what's in there.
To get rid of this class of reports we'd probably have to palloc0 rather
than palloc almost everything, and that strikes me as useless overhead.
It would make more sense to tell valgrind to suppress these particular
events in XLogInsert and XLogFlush.
AFAICS, if we actually had an uninitialized field (rather than
uninitialized padding) it would get detected at the point where the
field is used. If you run with large enough shared_buffers to avoid
having to discard pages from shmem, I think this would be detected even
across a (nominal) disk write and read.
BTW, there is something in the valgrind manual about adding hints to
teach valgrind about custom alloc/free mechanisms. Has anyone taught
it about palloc?
regards, tom lane