Thread: SIGSEGV in sebselect.
Hi All, I'm getting a SIGSEGV with the following subselect:- select * from disks where diskid in ( select distinct diskid from tracks where artist = 'Led Zeppelin'); The source tree is a cvsup from 22nd Feb (AM GMT) Platform is Linux/SPARC I'm afraid my debugging skills are limited to generating a backtrace so here goes.... Keith. Program received signal SIGSEGV, Segmentation fault. 0xe0104ee4 in strlen () (gdb) bt #0 0xe0104ee4 in strlen () #1 0xd1264 in pstrdup (string=0x0) at palloc.c:115 #2 0x696c0 in _copyUnique (from=0x1b0b90) at copyfuncs.c:552 #3 0x6abdc in copyObject (from=0x1b0b90) at copyfuncs.c:1687 #4 0x69754 in _copySubPlan (from=0x1a83d0) at copyfuncs.c:594 #5 0x6abfc in copyObject (from=0x1a83d0) at copyfuncs.c:1693 #6 0x698b0 in _copyExpr (from=0x1b1f90) at copyfuncs.c:679 #7 0x6ac2c in copyObject (from=0x1b1f90) at copyfuncs.c:1706 #8 0x6a304 in _copyCInfo (from=0x1b1710) at copyfuncs.c:1334 #9 0x6ad5c in copyObject (from=0x1b1710) at copyfuncs.c:1767 #10 0x6ae54 in copyObject (from=0x1b2d10) at copyfuncs.c:1829 #11 0x7e8b8 in create_seqscan_path (rel=0x1b0a90) at pathnode.c:228 #12 0x737c4 in find_rel_paths (root=0x15d390, rels=0x1b2f70) at allpaths.c:118 #13 0x73778 in find_paths (root=0x15d390, rels=0x1b2f70) at allpaths.c:72 #14 0x78ae4 in subplanner (root=0x15d390, flat_tlist=0x1ae330, qual=0x1ae3f0) at planmain.c:271 #15 0x789fc in query_planner (root=0x15d390, command_type=1, tlist=0x1aa910, qual=0x1ae3f0) at planmain.c:181 #16 0x79040 in union_planner (parse=0x15d390) at planner.c:138 #17 0x78f2c in planner (parse=0x15d390) at planner.c:72 #18 0xa80f4 in pg_parse_and_plan ( query_string=0xefffdc38 "select * from disks where diskid in ( select distinct diskid from tracks where artist = 'Led Zeppelin');", typev=0x0, nargs=0, queryListP=0xefffdb64, dest=Remote) at postgres.c:534 #19 0xa81e0 in pg_exec_query_dest ( query_string=0xefffdc38 "select * from disks where diskid in ( select distinct diskid from tracks where artist = 'Led Zeppelin');", argv=0x0, typev=0x0, nargs=0, dest=Remote) at postgres.c:615 #20 0xa81bc in pg_exec_query ( query_string=0xefffdc38 "select * from disks where diskid in ( select distinct diskid from tracks where artist = 'Led Zeppelin');", argv=0x0, typev=0x0, nargs=0) at postgres.c:597 #21 0xa90c4 in PostgresMain (argc=1122304, argv=0xeffffc38) at postgres.c:1373 #22 0x68788 in main (argc=11, argv=0xeffffd04) at main.c:97
This is a bug. I can reproduct it here with: select * from pguser where usesysid in (select distinct usesysid from pg_user); The Unique node copy has a NULL uniqueAttr value. Vadim is this related to subselect distinct handling, or is there some larger bug here? > > Hi All, > > I'm getting a SIGSEGV with the following subselect:- > > select * from disks where diskid in > ( select distinct diskid from tracks where artist = 'Led Zeppelin'); > > The source tree is a cvsup from 22nd Feb (AM GMT) > Platform is Linux/SPARC > > I'm afraid my debugging skills are limited to generating a backtrace > so here goes.... > > Keith. > > Program received signal SIGSEGV, Segmentation fault. > 0xe0104ee4 in strlen () > (gdb) bt > #0 0xe0104ee4 in strlen () > #1 0xd1264 in pstrdup (string=0x0) at palloc.c:115 > #2 0x696c0 in _copyUnique (from=0x1b0b90) at copyfuncs.c:552 > #3 0x6abdc in copyObject (from=0x1b0b90) at copyfuncs.c:1687 > #4 0x69754 in _copySubPlan (from=0x1a83d0) at copyfuncs.c:594 > #5 0x6abfc in copyObject (from=0x1a83d0) at copyfuncs.c:1693 > #6 0x698b0 in _copyExpr (from=0x1b1f90) at copyfuncs.c:679 > #7 0x6ac2c in copyObject (from=0x1b1f90) at copyfuncs.c:1706 > #8 0x6a304 in _copyCInfo (from=0x1b1710) at copyfuncs.c:1334 > #9 0x6ad5c in copyObject (from=0x1b1710) at copyfuncs.c:1767 > #10 0x6ae54 in copyObject (from=0x1b2d10) at copyfuncs.c:1829 > #11 0x7e8b8 in create_seqscan_path (rel=0x1b0a90) at pathnode.c:228 > #12 0x737c4 in find_rel_paths (root=0x15d390, rels=0x1b2f70) at allpaths.c:118 > #13 0x73778 in find_paths (root=0x15d390, rels=0x1b2f70) at allpaths.c:72 > #14 0x78ae4 in subplanner (root=0x15d390, flat_tlist=0x1ae330, qual=0x1ae3f0) at > planmain.c:271 > #15 0x789fc in query_planner (root=0x15d390, command_type=1, tlist=0x1aa910, > qual=0x1ae3f0) at planmain.c:181 > #16 0x79040 in union_planner (parse=0x15d390) at planner.c:138 > #17 0x78f2c in planner (parse=0x15d390) at planner.c:72 > #18 0xa80f4 in pg_parse_and_plan ( > query_string=0xefffdc38 "select * from disks where diskid in ( select > distinct diskid from tracks where artist = 'Led Zeppelin');", typev=0x0, > nargs=0, queryListP=0xefffdb64, dest=Remote) at postgres.c:534 > #19 0xa81e0 in pg_exec_query_dest ( > query_string=0xefffdc38 "select * from disks where diskid in ( select > distinct diskid from tracks where artist = 'Led Zeppelin');", argv=0x0, > typev=0x0, nargs=0, dest=Remote) at postgres.c:615 > #20 0xa81bc in pg_exec_query ( > query_string=0xefffdc38 "select * from disks where diskid in ( select > distinct diskid from tracks where artist = 'Led Zeppelin');", argv=0x0, > typev=0x0, nargs=0) at postgres.c:597 > #21 0xa90c4 in PostgresMain (argc=1122304, argv=0xeffffc38) at postgres.c:1373 > #22 0x68788 in main (argc=11, argv=0xeffffd04) at main.c:97 > > > -- Bruce Momjian maillist@candle.pha.pa.us
> > Hi All, > > I'm getting a SIGSEGV with the following subselect:- > > select * from disks where diskid in > ( select distinct diskid from tracks where artist = 'Led Zeppelin'); > > The source tree is a cvsup from 22nd Feb (AM GMT) > Platform is Linux/SPARC > > I'm afraid my debugging skills are limited to generating a backtrace > so here goes.... This is a partial fix. In make_unique(), if Query->uniqueAttr is '*', Unique->uniqueAttr gets null. However, with this fix, I get: test=> select usesysid from pg_user where usesysid in (select distinct usesysid from pg_user); ERROR: ExecReScan: node type 24 not supported I have not installed this patch yet until Vadim comments and perhaps has an idea on the ExecReScan message: --------------------------------------------------------------------------- *** ./backend/nodes/copyfuncs.c.orig Sun Feb 22 18:58:59 1998 --- ./backend/nodes/copyfuncs.c Sun Feb 22 19:03:37 1998 *************** *** 549,555 **** * copy remainder of node * ---------------- */ ! newnode->uniqueAttr = pstrdup(from->uniqueAttr); newnode->uniqueAttrNum = from->uniqueAttrNum; Node_Copy(from, newnode, uniquestate); --- 549,558 ---- * copy remainder of node * ---------------- */ ! if (newnode->uniqueAttr) ! newnode->uniqueAttr = pstrdup(from->uniqueAttr); ! else ! newnode->uniqueAttr = NULL; newnode->uniqueAttrNum = from->uniqueAttrNum; Node_Copy(from, newnode, uniquestate); -- Bruce Momjian maillist@candle.pha.pa.us
Bruce Momjian wrote: > > This is a partial fix. In make_unique(), if Query->uniqueAttr is '*', > Unique->uniqueAttr gets null. However, with this fix, I get: > > test=> select usesysid from pg_user where usesysid in (select distinct > usesysid from pg_user); > ERROR: ExecReScan: node type 24 not supported > > I have not installed this patch yet until Vadim comments and perhaps has > an idea on the ExecReScan message: Patch is Ok. DISTINCT is yet another node without re-scan support. Hope to add it in 1-2 days. Vadim
> > Bruce Momjian wrote: > > > > This is a partial fix. In make_unique(), if Query->uniqueAttr is '*', > > Unique->uniqueAttr gets null. However, with this fix, I get: > > > > test=> select usesysid from pg_user where usesysid in (select distinct > > usesysid from pg_user); > > ERROR: ExecReScan: node type 24 not supported > > > > I have not installed this patch yet until Vadim comments and perhaps has > > an idea on the ExecReScan message: > > Patch is Ok. DISTINCT is yet another node without re-scan support. > Hope to add it in 1-2 days. I have applied my patch. -- Bruce Momjian maillist@candle.pha.pa.us