Thread

  1. Re: [HACKERS] SIGSEGV in sebselect.

    Keith Parks <emkxp01@mtcc.demon.co.uk> — 1998-02-22T22:22:32Z

    Hi,
    
    Yes, it's definitely related to the DISTINCT clause.
    
    If I drop the distinct, which isn't needed anyway, the query works fine.
    
    Keith.
    
    
    Bruce Momjian <maillist@candle.pha.pa.us>
    > 
    > 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
    >