Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Feb 6, 2018 at 10:46 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> ... I, at least, don't have that understanding from looking
>> at the thread. For one thing, Peter has not explained why this issue
>> appears now with parallel index build when it did not before; it's
>> not like logtape.c isn't old enough to vote.
> Yeah, he has actually. In other cases, the buffer is guaranteed to
> have been filled at least once (and thus, from valgrind's point of
> view, is initialized) because if that weren't going to happen then we
> would have not have switched to a tape-sort in the first place. You
> can't set work_mem smaller than 8kB. But in the parallel case each
> worker must always produce a tape, so it can happen if a worker is
> unlucky enough to get only a very small slice of the data (because the
> other participants gobble it all up before that process really gets
> going).
Ah, I see. So this is really a problem that's been latent all along,
but was never exposed in any previous use-case for logtape.c.
> But what I really need here is
> some input on an option you do like, not just a list of things you
> don't like.
I like the option of doing VALGRIND_MAKE_MEM_DEFINED on the tail
portion of the buffer before writing it. That seems pretty tightly
tied to the behavior we're decreeing valid, whereas the suppression
is not.
regards, tom lane
