Re: BUG #16162: create index using gist_trgm_ops leads to panic

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #16162: create index using gist_trgm_ops leads to panic
Дата
Msg-id 26141.1576158262@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #16162: create index using gist_trgm_ops leads to panic  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Ответы Re: BUG #16162: create index using gist_trgm_ops leads to panic  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-bugs
Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> This only happens on some runs (in my case the CREATE INDEX passed 8x
> without any issue and failed on 9th iteration), so there has to be some
> random element affecting this.

As far as that goes, gistchoose() intentionally makes random choices
when two insertion paths seem equally good.  So failing only sometimes
isn't very surprising.

> so maybe the GIST stack is stale, not updated, or something like that. I
> think I've seen an issue mentioning that recently ... yep, found it [1].
> And I see Tom came to about the same conclusion, pointing to the same
> place in gistfinishsplit. It's only a couple days old, I don't think
> I've seen any proposed fixes yet.

Good that we seem to have just one bug there not two :-(.  I've not
looked any further than my previous message, though.

I wonder if this could be a recently-introduced bug?  I do not
recall seeing complaints like this before v12.

            regards, tom lane



В списке pgsql-bugs по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: BUG #16153: foreign key update should probably move dependentrows in the case of tuple rerouting
Следующее
От: PG Bug reporting form
Дата:
Сообщение: BUG #16163: Seq scan through all the partitions on a partitioned table when joined small, dictionary table.