Re: BUG #17406: Segmentation fault on GiST index after 14.2 upgrade

On 2/15/22 18:32, PG Bug reporting form wrote:
> The following bug has been logged on the website:
> 
> Bug reference:      17406
> Logged by:          Victor Yegorov
> Email address:      vyegorov@gmail.com
> PostgreSQL version: 14.2
> Operating system:   Ubuntu 18.04.6 LTS (bionic)
> Description:
> 
> KVM guest, on Intel(R) Xeon(R) CPU E5-2697 v2.
> 
> PostgreSQL 12.9 had been upgraded to 14.2 using
> 
> pg_upgradecluster -k  -m link 12 main /mnt/postgres/14/
> 
> After that, one of the queries is crashing with Segmentation Fault.
> However, after REINDEX problem will be fixed. I thought I should report
> still.
> 

Hmm. So I guess there are three options:

1) The index was already broken on 12.9, but for some reason (choice of 
a different plan, ...) it was not causing any issues.

2) The index got broken during/after the upgrade, for some reason.

3) The index is fine, but there's a newly introduced bug in ltree (or 
gist in general).

Hard to say which it is.

How large is the table/index? Are you able to run the query with a 
custom build (without values optimized out)? Any chance you still have a 
backup from before the pg_upgrade, on which you might run the query?

> explain
> SELECT r.id, r.name, r.map_center_y, r.map_center_x,
>         COALESCE ((SELECT string_agg(id::TEXT, ',') FROM v3_region AS r2
> WHERE r2.id != r.id AND r2.ltree_path <@ r.ltree_path), '') AS children
>    FROM v3_region AS r;
>                                                   QUERY PLAN
> -------------------------------------------------------------------------------------------------------------
>   Seq Scan on v3_region r  (cost=0.00..3207.31 rows=349 width=580)
>     SubPlan 1
>       ->  Aggregate  (cost=8.17..8.18 rows=1 width=32)
>             ->  Index Scan using region_ltree_path_idx_gist on v3_region r2
> (cost=0.14..8.16 rows=1 width=4)
>                   Index Cond: (ltree_path <@ r.ltree_path)
>                   Filter: (id <> r.id)
> (6 rows)
> 
> Here is backtrace:
> #0  __memmove_sse2_unaligned_erms () at
> ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:435
> #1  0x00007f129244c266 in memcpy (__len=<optimized out>,
> __src=0x55bbbd430f4a, __dest=<optimized out>) at
> /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
> #2  copy_ltree (src=0x55bbbd430f4a) at
> ./build/../contrib/ltree/ltree_gist.c:446
> #3  0x00007f129244db51 in gist_ischild (siglen=28, query=0x55bbbd410cb8,
> key=0x55bbbd430f18) at ./build/../contrib/ltree/ltree_gist.c:454

Interesting. Too bad the memcpy() parameters are optimized out. But 
clearly src is not NULL, so perhas something is wrong with the dst pointer?

> #4  ltree_consistent (fcinfo=0x7ffdac2e3e20) at
> ./build/../contrib/ltree/ltree_gist.c:674
> #5  0x000055bbbb944a5d in FunctionCall5Coll
> (flinfo=flinfo@entry=0x55bbbd416b20, collation=<optimized out>,
> arg1=arg1@entry=140727492165472, arg2=<optimized out>, arg3=<optimized out>,
> arg4=<optimized out>, arg5=140727492165471)
>      at ./build/../src/backend/utils/fmgr/fmgr.c:1241
> #6  0x000055bbbb4db72d in gistindex_keytest (recheck_distances_p=<synthetic
> pointer>, recheck_p=<synthetic pointer>, offset=4, page=0x7f1293a45180
> "K\313\003", tuple=0x7f1293a47058, scan=0x55bbbd4196c8)
>      at ./build/../src/backend/access/gist/gistget.c:222
> #7  gistScanPage (scan=scan@entry=0x55bbbd4196c8,
> pageItem=pageItem@entry=0x7ffdac2e3fe0, myDistances=myDistances@entry=0x0,
> tbm=tbm@entry=0x0, ntids=ntids@entry=0x0) at
> ./build/../src/backend/access/gist/gistget.c:438

Can you print the pageItem->blkno? That should tell us which index page 
is causing issues. And then you can dump the page using pageinspect [1]. 
For example if blkno = 100, then this might tell us more:

  SELECT * FROM
  gist_page_opaque_info(get_raw_page('region_ltree_path_idx_gist', 100));

  SELECT * FROM
  gist_page_items(get_raw_page('region_ltree_path_idx_gist', 100),
                               'region_ltree_path_idx_gist');

  SELECT * FROM
  gist_page_items_bytea(get_raw_page('region_ltree_path_idx_gist', 0));


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company