Re: BUG #16162: create index using gist_trgm_ops leads to panic - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #16162: create index using gist_trgm_ops leads to panic
Date
Msg-id 26141.1576158262@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #16162: create index using gist_trgm_ops leads to panic  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: BUG #16162: create index using gist_trgm_ops leads to panic  (Jeff Janes <jeff.janes@gmail.com>)
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: BUG #16153: foreign key update should probably move dependentrows in the case of tuple rerouting
Next
From: PG Bug reporting form
Date:
Subject: BUG #16163: Seq scan through all the partitions on a partitioned table when joined small, dictionary table.