Re: pgsql: Fix building of large (bigger than shared_buffers) hash indexes.

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql: Fix building of large (bigger than shared_buffers) hash indexes.
Date: 2016-06-27 21:27:23
Message-ID: 20160627212723.GA6301@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

On Fri, Jun 24, 2016 at 08:57:47PM +0000, Tom Lane wrote:
> Fix building of large (bigger than shared_buffers) hash indexes.
>
> When the index is predicted to need more than NBuffers buckets,
> CREATE INDEX attempts to sort the index entries by hash key before
> insertion, so as to reduce thrashing. This code path got broken by
> commit 9f03ca915196dfc8, which overlooked that _hash_form_tuple() is not
> just an alias for index_form_tuple(). The index got built anyway, but
> with garbage data, so that searches for pre-existing tuples always
> failed. Fix by refactoring to separate construction of the indexable
> data from calling index_form_tuple().
>
> Per bug #14210 from Daniel Newman. Back-patch to 9.5 where the
> bug was introduced.
>
> Report: <20160623162507(dot)17237(dot)39471(at)wrigleys(dot)postgresql(dot)org>

Do we have any way of helping people find out if they need to recreate
their hash indexes?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Peter Geoghegan 2016-06-27 21:30:53 Re: pgsql: Fix building of large (bigger than shared_buffers) hash indexes.
Previous Message Tom Lane 2016-06-27 19:58:01 pgsql: Fix CREATE MATVIEW/CREATE TABLE AS ... WITH NO DATA to not plan