Re: pgsql: Avoid valgrind complaint about write() of uninitalized bytes. - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: pgsql: Avoid valgrind complaint about write() of uninitalized bytes.
Date
Msg-id CAH2-WzkUjvzhr+vSoQWWsURk2c7O4tzcwLzVOk1rBJ_RWt-4cg@mail.gmail.com
Whole thread Raw
In response to Re: pgsql: Avoid valgrind complaint about write() of uninitalized bytes.  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: pgsql: Avoid valgrind complaint about write() of uninitalized bytes.
Re: pgsql: Avoid valgrind complaint about write() of uninitalized bytes.
List pgsql-hackers
On Wed, Feb 21, 2018 at 10:55 AM, Peter Geoghegan <pg@bowt.ie> wrote:
> Sure, but it looks like it has the exact same underlying cause to the
> LogicalTapeFreeze() issue. It shouldn't be very hard to write an
> equivalent patch for LogicalTapeRewindForRead() -- I pointed out that
> this could happen there instead before the first patch went in, in
> fact. My mistake was to imagine that that could never happen during
> the regression tests.

Attached patch does this. I cannot recreate this issue locally, but
this should still fix it on skink.

> Should we even be doing a parallel external sort here? It's hardly
> part of an intentional effort to test the code. I had to push to get
> us to give external sorts test coverage at one point about 18 months
> ago, because of concerns about the overhead/duration of external
> sorts. Not that I feel strongly about this myself.

I suppose that we should commit this patch, even if we subsequently
suppress parallel CREATE INDEX in the multiple-row-versions isolation
test.

-- 
Peter Geoghegan

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [doc fix] Correct calculation of vm.nr_hugepages
Next
From: Justin Pryzby
Date:
Subject: Re: [doc fix] Correct calculation of vm.nr_hugepages