Re: pgsql: Fix building of large (bigger than shared_buffers) hash indexes.
От | Bruce Momjian |
---|---|
Тема | Re: pgsql: Fix building of large (bigger than shared_buffers) hash indexes. |
Дата | |
Msg-id | 20160627212723.GA6301@momjian.us обсуждение исходный текст |
Ответ на | pgsql: Fix building of large (bigger than shared_buffers) hash indexes. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgsql: Fix building of large (bigger than
shared_buffers) hash indexes.
Re: pgsql: Fix building of large (bigger than shared_buffers) hash indexes. |
Список | 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.17237.39471@wrigleys.postgresql.org> Do we have any way of helping people find out if they need to recreate their hash indexes? -- Bruce Momjian <bruce@momjian.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 +
В списке pgsql-committers по дате отправления: