SIGSEGV in sebselect.

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,

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

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

"Vadim B. Mikheev" <vadim@sable.krasnoyarsk.su>

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.

Looks like you've done your usual magic Vadim/Bruce.

Grabbed a cvsup this morning, built and tested fine.

Thanks,
Keith.