Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column
От | Tom Lane |
---|---|
Тема | Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column |
Дата | |
Msg-id | 12194.1466724741@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #14210: filter by "=" constraint doesn't work when hash index is present on a column (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
I wrote: > So the answer is that this got broken by commit 9f03ca915196dfc8, > which appears to have imagined that _hash_form_tuple() is just an > alias for index_form_tuple(). But it ain't. As a result, construction > of hash indexes larger than shared_buffers is broken in 9.5 and up: BTW, an easy way to prove that the _h_spool code path is broken is to do this: diff --git a/src/backend/access/hash/hash.c b/src/backend/access/hash/hash.c index 49a6c81..162cb63 100644 --- a/src/backend/access/hash/hash.c +++ b/src/backend/access/hash/hash.c @@ -125,7 +125,7 @@ hashbuild(Relation heap, Relation index, IndexInfo *indexInfo) * NOTE: this test will need adjustment if a bucket is ever different from * one page. */ - if (num_buckets >= (uint32) NBuffers) + if (1) buildstate.spool = _h_spoolinit(heap, index, num_buckets); else buildstate.spool = NULL; and then run the regression tests. I'm thinking it would be a good idea to provide some less-painful way to force that code path to be taken for testing purposes. regards, tom lane
В списке pgsql-bugs по дате отправления: