Thread: BUG #6407: Crash on queries to gin index with multiply values

The following bug has been logged on the website:

Bug reference:      6407
Logged by:          Yury Don
Email address:      don@rosfirm.ru
PostgreSQL version: 9.1.2
Operating system:   Linux (Debian)
Description:=20=20=20=20=20=20=20=20

When making "in" query to fiels with gin index, server crashes. Below=20
create table tmp(id serial not null primary key, f1 integer, f2 text);
insert into tmp (f1,f2) values (1,'a'),(2,'b'),(3,'c');
create index tmp_f1_idx on tmp using gin (f1);
create index tmp_f2_idx on tmp using gin (f2);
set enable_seqscan to off;
select * from tmp where f1 in (1, 2);
After this query server chrashes:
server process (PID ...) was terminated by signal 11: Segmentation fault
The same after query on text field:
select * from tmp where f2 in ('a', 'd');

don@rosfirm.ru writes:
> When making "in" query to fiels with gin index, server crashes. Below
> create table tmp(id serial not null primary key, f1 integer, f2 text);
> insert into tmp (f1,f2) values (1,'a'),(2,'b'),(3,'c');
> create index tmp_f1_idx on tmp using gin (f1);
> create index tmp_f2_idx on tmp using gin (f2);

I assume you've got contrib/btree_gin installed?  Because in a bare
server those CREATE INDEX commands wouldn't work at all.

> set enable_seqscan to off;
> select * from tmp where f1 in (1, 2);
> After this query server chrashes:
> server process (PID ...) was terminated by signal 11: Segmentation fault
> The same after query on text field:
> select * from tmp where f2 in ('a', 'd');

FWIW, works for me.  Do you have any nonstandard settings that might
affect this?  Is it possible you've got a copy of btree_gin.so that
isn't compatible with your server?

            regards, tom lane

Tom Lane <tgl@sss.pgh.pa.us> writes:

> don@rosfirm.ru writes:
> > When making "in" query to fiels with gin index, server crashes. Below
> > create table tmp(id serial not null primary key, f1 integer, f2 text);
> > insert into tmp (f1,f2) values (1,'a'),(2,'b'),(3,'c');
> > create index tmp_f1_idx on tmp using gin (f1);
> > create index tmp_f2_idx on tmp using gin (f2);
>
> I assume you've got contrib/btree_gin installed?  Because in a bare
> server those CREATE INDEX commands wouldn't work at all.
>
> > set enable_seqscan to off;
> > select * from tmp where f1 in (1, 2);
> > After this query server chrashes:
> > server process (PID ...) was terminated by signal 11: Segmentation fault
> > The same after query on text field:
> > select * from tmp where f2 in ('a', 'd');
>
> FWIW, works for me.  Do you have any nonstandard settings that might
> affect this?  Is it possible you've got a copy of btree_gin.so that
> isn't compatible with your server?

Can reproduce in Debian testing:
postgresql-9.1: 9.1.2-4
postgresql-contrib-9.1: 9.1.2-4
postgresql-9.1-dbg: 9.1.2-4

PostgreSQL 9.1.2 on x86_64-unknown-linux-gnu, compiled by gcc-4.6.real (Debian 4.6.2-9) 4.6.2, 64-bit

======== backtrace ========
#0  0x00007fe1efbbc16d in list_head (l=0x1b) at
/home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/include/nodes/pg_list.h:82
#1  0x00007fe1efbbc2b2 in get_leftop (clause=0x7fe1f1d85230) at
/home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/optimizer/util/clauses.c:189
#2  0x00007fe1efcc22d0 in gincostestimate (fcinfo=0x7fff990f9710) at
/home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/utils/adt/selfuncs.c:6589
#3  0x00007fe1efd391b4 in OidFunctionCall9Coll (functionId=2741, collation=0, arg1=140608401853872,
arg2=140608401852208,arg3=140608401905056, arg4=0, arg5=0, arg6=140735761324864, arg7=140735761324872,
arg8=140735761324880,arg9=140735761324888) at
/home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/utils/fmgr/fmgr.c:1860
#4  0x00007fe1efb8d697 in cost_index (path=0x7fe1f1d84b70, root=0x7fe1f1d84db0, index=0x7fe1f1d84730,
indexQuals=0x7fe1f1d915a0,indexOrderBys=0x0, outer_rel=0x0) at
/home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/optimizer/path/costsize.c:268
#5  0x00007fe1efbc3f56 in create_index_path (root=0x7fe1f1d84db0, index=0x7fe1f1d84730, clause_groups=0x7fe1f1d91550,
indexorderbys=0x0,pathkeys=0x0, indexscandir=NoMovementScanDirection, outer_rel=0x0) at
/home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/optimizer/util/pathnode.c:513
#6  0x00007fe1efb95d4d in find_usable_indexes (root=0x7fe1f1d84db0, rel=0x7fe1f1d18050, clauses=0x7fe1f1d85de8,
outer_clauses=0x0,istoplevel=1 '\001', outer_rel=0x0, saop_control=SAOP_REQUIRE, scantype=ST_BITMAPSCAN) at
/home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/optimizer/path/indxpath.c:441
#7  0x00007fe1efb95ef9 in find_saop_paths (root=0x7fe1f1d84db0, rel=0x7fe1f1d18050, clauses=0x7fe1f1d85de8,
outer_clauses=0x0,istoplevel=1 '\001', outer_rel=0x0) at
/home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/optimizer/path/indxpath.c:514
#8  0x00007fe1efb959f0 in create_index_paths (root=0x7fe1f1d84db0, rel=0x7fe1f1d18050) at
/home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/optimizer/path/indxpath.c:236
#9  0x00007fe1efb8aa98 in set_plain_rel_pathlist (root=0x7fe1f1d84db0, rel=0x7fe1f1d18050, rte=0x7fe1f1d18270) at
/home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/optimizer/path/allpaths.c:277
#10 0x00007fe1efb8a8e4 in set_rel_pathlist (root=0x7fe1f1d84db0, rel=0x7fe1f1d18050, rti=1, rte=0x7fe1f1d18270) at
/home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/optimizer/path/allpaths.c:192
#11 0x00007fe1efb8a818 in set_base_rel_pathlists (root=0x7fe1f1d84db0) at
/home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/optimizer/path/allpaths.c:162
#12 0x00007fe1efb8a793 in make_one_rel (root=0x7fe1f1d84db0, joinlist=0x7fe1f1d85768) at
/home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/optimizer/path/allpaths.c:98
#13 0x00007fe1efba97bc in query_planner (root=0x7fe1f1d84db0, tlist=0x7fe1f1d85080, tuple_fraction=0, limit_tuples=-1,
cheapest_path=0x7fff990fa068,sorted_path=0x7fff990fa070, num_groups=0x7fff990fa058) at
/home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/optimizer/plan/planmain.c:271
#14 0x00007fe1efbab63f in grouping_planner (root=0x7fe1f1d84db0, tuple_fraction=0) at
/home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/optimizer/plan/planner.c:1150
#15 0x00007fe1efbaa761 in subquery_planner (glob=0x7fe1f1d84ae0, parse=0x7fe1f1d18160, parent_root=0x0, hasRecursion=0
'\000',tuple_fraction=0, subroot=0x7fff990fa2b8) at
/home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/optimizer/plan/planner.c:539
#16 0x00007fe1efba9e80 in standard_planner (parse=0x7fe1f1d18160, cursorOptions=0, boundParams=0x0) at
/home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/optimizer/plan/planner.c:202
#17 0x00007fe1efba9cd5 in planner (parse=0x7fe1f1d18160, cursorOptions=0, boundParams=0x0) at
/home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/optimizer/plan/planner.c:129
#18 0x00007fe1efc2bd43 in pg_plan_query (querytree=0x7fe1f1d18160, cursorOptions=0, boundParams=0x0) at
/home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/tcop/postgres.c:723
#19 0x00007fe1efc2be03 in pg_plan_queries (querytrees=0x7fe1f1d84d80, cursorOptions=0, boundParams=0x0) at
/home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/tcop/postgres.c:782
#20 0x00007fe1efc2c122 in exec_simple_query (query_string=0x7fe1f1d170d0 "select * from tmp where f1 in (1, 2);") at
/home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/tcop/postgres.c:947
#21 0x00007fe1efc30991 in PostgresMain (argc=2, argv=0x7fe1f1c281f0, username=0x7fe1f1c28090 "seb") at
/home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/tcop/postgres.c:3926
#22 0x00007fe1efbe017d in BackendRun (port=0x7fe1f1c7d1e0) at
/home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/postmaster/postmaster.c:3601
#23 0x00007fe1efbdf75c in BackendStartup (port=0x7fe1f1c7d1e0) at
/home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/postmaster/postmaster.c:3286
#24 0x00007fe1efbdc679 in ServerLoop () at
/home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/postmaster/postmaster.c:1455
#25 0x00007fe1efbdbcff in PostmasterMain (argc=5, argv=0x7fe1f1c27180) at
/home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/postmaster/postmaster.c:1116
#26 0x00007fe1efb51899 in main (argc=5, argv=0x7fe1f1c27180) at
/home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/main/main.c:199

======== /etc/postgresql/9.1/main/postgresql.conf ========
data_directory = '/var/lib/postgresql/9.1/main'         # use data in another directory
hba_file = '/etc/postgresql/9.1/main/pg_hba.conf'       # host-based authentication file
ident_file = '/etc/postgresql/9.1/main/pg_ident.conf'   # ident configuration file
external_pid_file = '/var/run/postgresql/9.1-main.pid'          # write an extra PID file
port = 5432                             # (change requires restart)
max_connections = 100                   # (change requires restart)
unix_socket_directory = '/var/run/postgresql'           # (change requires restart)
ssl = true                              # (change requires restart)
shared_buffers = 240MB                  # min 128kB
temp_buffers = 180MB                    # min 800kB
work_mem = 128MB                                # min 64kB
maintenance_work_mem = 316MB            # min 1MB
synchronous_commit = off                # synchronization level; on, off, or local
effective_cache_size = 1528MB
constraint_exclusion = on               # on, off, or partition
log_min_messages = notice               # values in order of decreasing detail:
log_connections = on
log_disconnections = on
log_line_prefix = '%t '                 # special values:
log_lock_waits = on                     # log lock waits >= deadlock_timeout
log_temp_files = 0                      # log temporary files equal or larger
datestyle = 'iso, dmy'
lc_messages = 'ru_RU.UTF-8'                     # locale for system error message
lc_monetary = 'ru_RU.UTF-8'                     # locale for monetary formatting
lc_numeric = 'ru_RU.UTF-8'                      # locale for number formatting
lc_time = 'ru_RU.UTF-8'                         # locale for time formatting
default_text_search_config = 'pg_catalog.russian'
custom_variable_classes = 'custom,plperl,plperlu'               # list of custom variable class names
plperl.use_strict = true
plperlu.use_strict = true


--
Sergey Burladyan

Sergey Burladyan <eshkinkot@gmail.com> writes:

> #1  0x00007fe1efbbc2b2 in get_leftop (clause=0x7fe1f1d85230) at
/home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/optimizer/util/clauses.c:189

I set breakpoint at src/backend/optimizer/util/clauses.c:188 and do some trace,
may be this can help:
Breakpoint 1, get_leftop (clause=0x7fe1f1d5af30)
(gdb) print *expr
$1 = {xpr = {type = T_OpExpr}, opno = 96, opfuncid = 65, opresulttype = 16, opretset = 0 '\000', opcollid = 0,
  inputcollid = 0, args = 0x7fe1f1d5cb98, location = 0}
Breakpoint 1, get_leftop (clause=0x7fe1f1d5c4b0)
(gdb) print *expr
$2 = {xpr = {type = T_OpExpr}, opno = 96, opfuncid = 65, opresulttype = 16, opretset = 0 '\000', opcollid = 0,
  inputcollid = 0, args = 0x7fe1f1d5cc40, location = 0}
Breakpoint 1, get_leftop (clause=0x7fe1f1d5c0b8)
(gdb) print *expr
$3 = {xpr = {type = T_ScalarArrayOpExpr}, opno = 96, opfuncid = 65, opresulttype = 1, opretset = 0 '\000', opcollid =
0, 
  inputcollid = 4057317752, args = 0x1b, location = -237649736}

--
Sergey Burladyan

Ah, sorry, looks like it already fixed in
REL9_1_STABLE 5d7d12de56be2c746bfc30214d3300644e8dc0f3

Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Tue Dec 20 19:57:40 2011 -0500

    Fix gincostestimate to handle ScalarArrayOpExpr reasonably.



On Thu, Feb 2, 2012 at 4:35 AM, Sergey Burladyan <eshkinkot@gmail.com>wrote:

> Sergey Burladyan <eshkinkot@gmail.com> writes:
>
> > #1  0x00007fe1efbbc2b2 in get_leftop (clause=0x7fe1f1d85230) at
> /home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/optimizer/util/clauses.c:189
>
> I set breakpoint at src/backend/optimizer/util/clauses.c:188 and do some
> trace,
> may be this can help:
> Breakpoint 1, get_leftop (clause=0x7fe1f1d5af30)
> (gdb) print *expr
> $1 = {xpr = {type = T_OpExpr}, opno = 96, opfuncid = 65, opresulttype =
> 16, opretset = 0 '\000', opcollid = 0,
>  inputcollid = 0, args = 0x7fe1f1d5cb98, location = 0}
> Breakpoint 1, get_leftop (clause=0x7fe1f1d5c4b0)
> (gdb) print *expr
> $2 = {xpr = {type = T_OpExpr}, opno = 96, opfuncid = 65, opresulttype =
> 16, opretset = 0 '\000', opcollid = 0,
>  inputcollid = 0, args = 0x7fe1f1d5cc40, location = 0}
> Breakpoint 1, get_leftop (clause=0x7fe1f1d5c0b8)
> (gdb) print *expr
> $3 = {xpr = {type = T_ScalarArrayOpExpr}, opno = 96, opfuncid = 65,
> opresulttype = 1, opretset = 0 '\000', opcollid = 0,
>  inputcollid = 4057317752, args = 0x1b, location = -237649736}
>
> --
> Sergey Burladyan
>

eshkinkot <eshkinkot@gmail.com> writes:
> Ah, sorry, looks like it already fixed in
> REL9_1_STABLE 5d7d12de56be2c746bfc30214d3300644e8dc0f3

Oh, of course.  I couldn't reproduce it because    I was testing 9.1
branch tip.

            regards, tom lane