Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On 2018-02-02 13:35:59 -0800, Peter Geoghegan wrote:
> On Fri, Feb 2, 2018 at 10:38 AM, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> > On Fri, Feb 2, 2018 at 10:37 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> >> If you could keep an eye on the buildfarm and investigate anything
> >> that breaks, I would appreciate it.
>
> > I can keep an eye on it throughout the day.
>
> There is a benign Valgrind error that causes the lousyjack animal to
> report failure. It looks like this:
>
> ==6850== Syscall param write(buf) points to uninitialised byte(s)
> ==6850== at 0x4E4D534: write (in /usr/lib64/libpthread-2.26.so)
> ==6850== by 0x82328F: FileWrite (fd.c:2017)
> ==6850== by 0x8261AD: BufFileDumpBuffer (buffile.c:513)
> ==6850== by 0x826569: BufFileFlush (buffile.c:657)
> ==6850== by 0x8262FB: BufFileRead (buffile.c:561)
> ==6850== by 0x9F6C79: ltsReadBlock (logtape.c:273)
> ==6850== by 0x9F7ACF: LogicalTapeFreeze (logtape.c:906)
> ==6850== by 0xA05B0D: worker_freeze_result_tape (tuplesort.c:4477)
> ==6850== by 0xA05BC6: worker_nomergeruns (tuplesort.c:4499)
> ==6850== by 0x9FCA1E: tuplesort_performsort (tuplesort.c:1823)

Not saying you're wrong, but you should include a comment on why this is
a benign warning. Presumably it's some padding memory somewhere, but
it's not obvious from the above bleat.

Greetings,

Andres Freund