Re: [BUGS] BUG #8143: Backend segmentation fault in pg_trgm

2013-05-10 Thread Joel Roller
That was quick.  Applied the 91715e82932665 commit directly against the 9.2.4 
pgdg source, fix works great.  Test data and the original breaking production 
queries run fine for me.  Thank you very much!

-joel



On May 9, 2013, at 6:19 PM, Tom Lane wrote:

 jrol...@rjobrien.com writes:
 We've come across a specific query and query plan that causes a repeatable
 segmentation fault on the postgresql backend.
 
 Ah, I see it: gistrescan() is trying to preserve the per-scankey
 fn_extra values to allow caching, but what it's doing does not work
 if more than one scankey refers to the same consistentFn, ie, the
 same index column.  A bit surprising we've not seen this before,
 because I think that code has been like that for awhile.
 
 Will fix, thanks for the report!
 
   regards, tom lane



-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs


[BUGS] BUG #8143: Backend segmentation fault in pg_trgm

2013-05-09 Thread jroller
The following bug has been logged on the website:

Bug reference:  8143
Logged by:  Joel Roller
Email address:  jrol...@rjobrien.com
PostgreSQL version: 9.2.4
Operating system:   Debian 6.0.7 + squeeze-pgdg
Description:

Howdy.

We've come across a specific query and query plan that causes a repeatable
segmentation fault on the postgresql backend.  

Thanks,
-joel


PostgreSQL 9.2.4 on x86_64-unknown-linux-gnu, compiled by gcc-4.4.real
(Debian 4.4.5-8) 4.4.5, 64-bit
from deb http://apt.postgresql.org/pub/repos/apt/ squeeze-pgdg main

-- System Information:
Debian Release: 6.0.7
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages postgresql-contrib-9.2 depends on:
ii  libc6  2.11.3-4  Embedded GNU C Library: Shared
lib
ii  libossp-uuid16 1.6.2-1   OSSP uuid ISO-C and C++ -
shared l
ii  libpq5 9.2.4-1.pgdg60+1  PostgreSQL C client library
ii  libssl0.9.80.9.8o-4squeeze14 SSL shared libraries
ii  libxml22.7.8.dfsg-2+squeeze7 GNOME XML library
ii  libxslt1.1 1.1.26-6+squeeze3 XSLT 1.0 processing library -
runt
ii  postgresql-9.2 9.2.4-1.pgdg60+1  object-relational SQL database,
ve
ii  zlib1g 1:1.2.3.4.dfsg-3  compression library - runtime


-- Crashing query:
select k.kw from keywords k, group_page_map gp
where gp.country = '99'
and gp.state is null and gp.city is null
and gp.group_id = k.group_id 
and k.kw like 'AB%' and k.kw like 'ABCD%';
-- Output:
The connection to the server was lost. Attempting reset: Failed.
! 


   QUERY PLAN   

-
 Nested Loop  (cost=0.00..137.43 rows=1 width=11)
   Join Filter: (k.group_id = gp.group_id)
   -  Seq Scan on group_page_map gp  (cost=0.00..92.81 rows=1 width=4)
 Filter: ((state IS NULL) AND (city IS NULL) AND ((country)::text =
'99'::text))
   -  Index Scan using tgm_kw_crash on keywords k  (cost=0.00..44.49
rows=10 width=15)
 Index Cond: (((kw)::text ~~ 'AB%'::text) AND ((kw)::text ~~
'ABCD%'::text))

# gdb /usr/lib/postgresql/9.2/bin/postgres postgres-12458.core
GNU gdb (GDB) 7.3-debian
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/lib/postgresql/9.2/bin/postgres...Reading symbols
from /usr/lib/debug/usr/lib/postgresql/9.2/bin/postgres...done.
done.
[New LWP 12458]

warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Core was generated by `postgres: roller htcrash [local] SELECT  
'.
Program terminated with signal 11, Segmentation fault.
#0  0x7ff4b9d9b5a7 in pfree (pointer=0x7ff4bb377818) at
/tmp/buildd/postgresql-9.2-9.2.4/build/../src/backend/utils/mmgr/mcxt.c:659
659
/tmp/buildd/postgresql-9.2-9.2.4/build/../src/backend/utils/mmgr/mcxt.c: No
such file or directory.
in
/tmp/buildd/postgresql-9.2-9.2.4/build/../src/backend/utils/mmgr/mcxt.c
(gdb) bt
#0  0x7ff4b9d9b5a7 in pfree (pointer=0x7ff4bb377818) at
/tmp/buildd/postgresql-9.2-9.2.4/build/../src/backend/utils/mmgr/mcxt.c:659
#1  0x7ff4b2f93c79 in gtrgm_consistent (fcinfo=0x7fff759b7a40) at
/tmp/buildd/postgresql-9.2-9.2.4/build/../contrib/pg_trgm/trgm_gist.c:245
#2  0x7ff4b9d81372 in FunctionCall5Coll (flinfo=0x7ff4bb377878,
collation=3140974616, arg1=optimized out, arg2=7088982889980756224,
arg3=140689089722480, arg4=140689089754640, arg5=140735166512862)
at
/tmp/buildd/postgresql-9.2-9.2.4/build/../src/backend/utils/fmgr/fmgr.c:1407
#3  0x7ff4b9aa8955 in gistindex_keytest (recheck_p=optimized out,
offset=optimized out, page=optimized out, tuple=optimized out,
scan=optimized out)
at
/tmp/buildd/postgresql-9.2-9.2.4/build/../src/backend/access/gist/gistget.c:139
#4  gistScanPage (scan=optimized out, pageItem=optimized out,
myDistances=optimized out, tbm=optimized out, ntids=optimized out)
at
/tmp/buildd/postgresql-9.2-9.2.4/build/../src/backend/access/gist/gistget.c:312
#5  0x7ff4b9aa9077 in gistgettuple (fcinfo=optimized out) at
/tmp/buildd/postgresql-9.2-9.2.4/build/../src/backend/access/gist/gistget.c:494
#6  0x7ff4b9d81603 in FunctionCall2Coll (flinfo=0x7ff4bb377878,
collation=3140974616, arg1=0, arg2=7088982889980756224) 

Re: [BUGS] BUG #8143: Backend segmentation fault in pg_trgm

2013-05-09 Thread Tom Lane
jrol...@rjobrien.com writes:
 We've come across a specific query and query plan that causes a repeatable
 segmentation fault on the postgresql backend.

Ah, I see it: gistrescan() is trying to preserve the per-scankey
fn_extra values to allow caching, but what it's doing does not work
if more than one scankey refers to the same consistentFn, ie, the
same index column.  A bit surprising we've not seen this before,
because I think that code has been like that for awhile.

Will fix, thanks for the report!

regards, tom lane


--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs