Re: pgsql: Support parallel btree index builds.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Peter Geoghegan <pg(at)bowt(dot)ie>, Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>, pgsql-committers <pgsql-committers(at)postgresql(dot)org>
Subject: Re: pgsql: Support parallel btree index builds.
Date: 2018-02-06 15:46:12
Message-ID: 6370.1517931972@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sun, Feb 4, 2018 at 1:11 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I'll be happier about it when the valgrind buildfarm animals are
>> happy.

> Me too, but it's not clear what the right fix is. One thing that
> would help is if you put in an appearance on the thread where this is
> being discussed and cast a vote. (Ditto to Andres.)

If you mean do I like fixing this by adding a valgrind suppression,
no I do not. Valgrind suppressions are last-resort band-aids IMO,
to be applied only when it's clearly understood what behavior we're
masking and why it's more reasonable to mask it than make it better
defined. 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.

Even granting that a suppression is the way to fix it, the proposed
suppression seems pretty darn broad, and hence likely to mask things
we'd wish it hadn't.

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Robert Haas 2018-02-06 15:59:56 Re: pgsql: Support parallel btree index builds.
Previous Message Robert Haas 2018-02-06 14:05:59 Re: pgsql: Support parallel btree index builds.

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2018-02-06 15:54:28 Re: RelOptInfo -> Relation
Previous Message Robert Haas 2018-02-06 15:42:00 Re: Crash in partition-wise join involving dummy partitioned relation