BUG #17215: ltree tests failing in REL_14_STABLE / commit cb8a5a588

PG Bug reporting form <noreply@postgresql.org> writes:

When running the contrib/ltree checks against a build on OSX 10.13 (yeah, I
know) against commit cb8a5a588e in REL_14_STABLE, am dying due to:

# SELECT * FROM ltreetest WHERE t = '12.3' order by t asc;
ERROR: unrecognized StrategyNumber: 6

Hm, the OSX members of the buildfarm aren't unhappy, and nobody else has
reported similar symptoms. You might try a full rebuild (tear it
down with "git clean -dfx" and start over).

regards, tom lane

On Tue, Oct 05, 2021 at 10:21:46PM +0000, PG Bug reporting form wrote:

When running the contrib/ltree checks against a build on OSX 10.13 (yeah, I
know) against commit cb8a5a588e in REL_14_STABLE, am dying due to:

# SELECT * FROM ltreetest WHERE t = '12.3' order by t asc;
ERROR: unrecognized StrategyNumber: 6

Adding Peter and Heikki here.

That may look like a corruption, but by re-running the tests this is
reproducible, right? Are you running a simple "make check"? Perhaps
you forgot to clean up your source directory before recompiling? Or
is that an installcheck on an existing instance, which has some
particular configuration not checked in the buildfarm? This query
uses only BTEqualStrategyNumber here. Now, it seems to me that this
could point to an actual bug, where the consistent function tries to
use a picksplit, but it should not in a certain code path. I am not
really a gist expert, just saying, but there are diffs between 13 and
14 in this area.
--
Michael

On Oct 5, 2021, at 10:14 PM, Michael Paquier <michael@paquier.xyz> wrote:

On Tue, Oct 05, 2021 at 10:21:46PM +0000, PG Bug reporting form wrote:

When running the contrib/ltree checks against a build on OSX 10.13 (yeah, I
know) against commit cb8a5a588e in REL_14_STABLE, am dying due to:

# SELECT * FROM ltreetest WHERE t = '12.3' order by t asc;
ERROR: unrecognized StrategyNumber: 6

Adding Peter and Heikki here.

That may look like a corruption, but by re-running the tests this is
reproducible, right? Are you running a simple "make check"? Perhaps
you forgot to clean up your source directory before recompiling? Or
is that an installcheck on an existing instance, which has some
particular configuration not checked in the buildfarm? This query
uses only BTEqualStrategyNumber here. Now, it seems to me that this
could point to an actual bug, where the consistent function tries to
use a picksplit, but it should not in a certain code path. I am not
really a gist expert, just saying, but there are diffs between 13 and
14 in this area.
--
Michael

I'm 'make distclean' and re-running configure between compilation runs. I've narrowed it down to the error being raised within ltree_gist.c's ltree_consistent(). Moreover, as a total gross hack guess / attempt, if I augment the switch(strategy) to handle RTSameStrategyNumber ( = 6 per stratnum.h) as equivalent to BTEqualStrategyNumber via an additional case statement:

--- a/contrib/ltree/ltree_gist.c
+++ b/contrib/ltree/ltree_gist.c
@@ -640,6 +640,7 @@ ltree_consistent(PG_FUNCTION_ARGS)
                        res = (ltree_compare((ltree *) query, LTG_GETLNODE(key, siglen)) >= 0);
                        break;
                case BTEqualStrategyNumber:
+               case RTSameStrategyNumber:
                        query = PG_GETARG_LTREE_P(1);
                        if (GIST_LEAF(entry))
                                res = (ltree_compare((ltree *) query, LTG_NODE(key)) == 0);

then 'make check' within contrib/ltree passes. Remove that added case, and it fails on what appears to be all of the gist indexed ltree equality queries in the regression suite:

diff -U3 /Users/jlrobins/pg-devel/git/contrib/ltree/expected/ltree.out /Users/jlrobins/pg-devel/git/contrib/ltree/results/ltree.out
--- /Users/jlrobins/pg-devel/git/contrib/ltree/expected/ltree.out	2020-06-30 10:31:51.000000000 -0400
+++ /Users/jlrobins/pg-devel/git/contrib/ltree/results/ltree.out	2021-10-05 23:16:19.000000000 -0400
@@ -5899,11 +5899,7 @@
 (124 rows)

 SELECT * FROM ltreetest WHERE t =  '12.3' order by t asc;
-  t   
-------
- 12.3
-(1 row)
-
+ERROR:  unrecognized StrategyNumber: 6
 SELECT * FROM ltreetest WHERE t >= '12.3' order by t asc;
                 t                 
 ----------------------------------
@@ -7839,11 +7835,7 @@
 (1 row)

 SELECT count(*) FROM ltreetest WHERE t =  '12.3';
- count 
--------
-     1
-(1 row)
-
+ERROR:  unrecognized StrategyNumber: 6
 SELECT count(*) FROM ltreetest WHERE t >= '12.3';
  count 
 -------

Can reproduce this using clang / llvm 11 and 12. Am cooking with:

./configure \
--with-includes=/opt/local/include \
--with-libraries=/opt/local/lib \
--prefix=/Users/jlrobins/pg-devel \
--with-llvm \
--with-perl --with-python --with-tcl \
-enable-nls --enable-cassert \
--enable-debug --with-libxml --with-libxslt --with-openssl \
--with-gssapi --enable-debug --with-icu

Could this 6 be coming from ltree--1.1.sql line 545:

CREATE OPERATOR CLASS gist_ltree_ops
DEFAULT FOR TYPE ltree USING gist AS
OPERATOR 1 < ,
OPERATOR 2 <= ,
OPERATOR 3 && ,
OPERATOR 4 >= ,
OPERATOR 5 > ,
OPERATOR 6 = ,
...

?

-----
James Robinson
james@jlr-photo.com
http://jlr-photo.com/

On Oct 5, 2021, at 11:56 PM, James Robinson <james@jlr-photo.com> wrote:

Could this 6 be coming from ltree--1.1.sql line 545:

CREATE OPERATOR CLASS gist_ltree_ops
DEFAULT FOR TYPE ltree USING gist AS
OPERATOR 1 < ,
OPERATOR 2 <= ,
OPERATOR 3 && ,
OPERATOR 4 >= ,
OPERATOR 5 > ,
OPERATOR 6 = ,
...

Yeah, it is. Somehow I had diffs in that file, including this added 'OPERATOR 6 =,' line in ltree--1.1.sql. Wacky. Git resetting hard has me passing again now.

Apologies for the noise; thanks.

-----
James Robinson
james@jlr-photo.com
http://jlr-photo.com/