Robert Haas <robertmh...@gmail.com> writes: > On Tue, Feb 6, 2018 at 10:46 AM, Tom Lane <t...@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