Hi All,



Anyone seen anything like this...Be warned that the query may produce a
SIGSEGV which may harm your installation...



1. On a remote installation running II 9.2.0 (a64.lnx/143)NPTL + p13643

createdb bowtest_ddb/star



2. On a seperate installation with a vnode pointing to the installation
used

at step 1



sql vnode::bowtest_ddb/star << SQL_END

create table My_Select_28731 as select table_name,table_owner

from iitables

\p\g

\q

SQL_END



If the problem exists then:

a. At the front end we see the message:

E_OP08A2 Unexpected exception occurred within query compilation

b. On the remote installations errlog we see a Segmentation
violation with

a stack trace:

-----------BEGIN STACK TRACE------------

0: 400777e0 iistar [0x9daa1e] <static function, no info available>

1: 40077d00 iistar [0x9da72d] <static function, no info available>

2: 40077d30 iistar [0x9dc4cf] <static function, no info available>

3: 40077e00 iistar(opc_pltext+0x120) [0x9dc7dd]( ... )

4: 40077e50 iistar(opc_dentry+0xde) [0x9cc08e]( ... )

5: 40077eb0 iistar(opc_cqp_continue+0x49c) [0x729597]( ... )

6: 40078100 iistar(opc_querycomp+0x4a3) [0x728878]( ... )

7: 40078130 iistar [0x4a34bd] <static function, no info available>

8: 40078150 iistar [0x4a360d] <static function, no info available>

9: 40078b10 iistar(ops_sequencer+0x25f) [0x4a387d]( ... )

10: 40078c40 iistar(opf_call+0x168) [0x4a2603]( ... )

11: 4007b050 iistar(scs_sequencer+0x3076) [0x484046]( ... )

12: 400831d0 iistar(CSMT_setup+0x50e) [0x6dc8fe]( ... )

-----------END STACK TRACE----------



3. Now access the remote installation directly and execute the same
query

without the vnode...it works.



Martin Bowes

On Feb 23, 4:55*pm, "Martin Bowes" <martin.bo... (AT) ctsu (DOT) ox.ac.uk> wrote:
I can reproduce a part of the problem. but get a SIGSEGV when running
this statement locally too, so no dependency on any vnode usage. ALso
the query may not fail all time(but almost all time).
You should open a servicedesk issue for this.

Regards
Kristoff

Hi Kristoff,

Yes I just managed the non vnode SIGSEGV as well. Also the strange case where it works and then just as quickly stops working!

Plus...rollback is broken.

I can create the table;rollback and the table is still present.

I think I'll raise this as an Issue.

Marty

-----Original Message-----
From: Kristoff [mailto:kristoff.picard (AT) ingres (DOT) com]
Sent: 24 February 2010 08:55
To: info-ingres (AT) kettleriverconsulting (DOT) com
Subject: Re: [Info-Ingres] Queries Sigsgev when run on remote star database

On Feb 23, 4:55*pm, "Martin Bowes" <martin.bo... (AT) ctsu (DOT) ox.ac.uk> wrote:
I can reproduce a part of the problem. but get a SIGSEGV when running
this statement locally too, so no dependency on any vnode usage. ALso
the query may not fail all time(but almost all time).
You should open a servicedesk issue for this.

Regards
Kristoff

_______________________________________________
Info-Ingres mailing list
Info-Ingres (AT) kettleriverconsulting (DOT) com
http://ext-cando.kettleriverconsulti...fo/info-ingres

The SIGSEGV happens on various 64bit platforms, but not in 32bit
installations. It appears that this problem came in somewhere between
patches 13443 and 13556 (on Linux). The problem is now known as bug
123347.
The rollback problem is different, it seems it has never worked
correctly in Star. After the rollback the table is no longer
accessible, but you need to drop the table before recreating it. This
is now known as bug 123348.

Kristoff

On Feb 26, 4:36*pm, Kristoff <kristoff.pic... (AT) ingres (DOT) com> wrote:
The SIGSEGV problem is now fixed.
The problem with rollback is not a bug, but a feature. For details
see the Star User Guide (use set "ddl_concurrency off" to change the
default behaviour)

Kristoff