Temporary Tables, Ingres 2.6, and E_OP0082
Marvin Hubenthal
I am in the process of moving a client's operations from 6.4 to 2.6.
In the process I would like to take advantage of some of the newer
features available, one being global temporary tables. In doing so,
I hit a problem. When I have a key of more than one column and
select based the columns of the key, an E_OP0082 consistency check
error is generated. The below sample and results from the errlog
illustrates the problem.
Can anyone suggest a possible cause and solution? The OS is
Solaris 8 and the Ingres is 2.6 off the CD. (I did not see
any patches available on the CA site.) Also, I could not
replicate the problem on 2.5 in Linux.
Thanks,
Marvin Hubenthal
Sophistry Inc.
declare global temporary table session.t (
a varchar(8), b varchar(8), c varchar(8), d f8)
on commit preserve rows with norecovery;
commit;
Executing . . .
continue
* * * insert into session.t values ('a', 'b', 'c', 1.0);
insert into session.t values ('z', 'b', 'c', 1.0);
commit;
Executing . . .
(1 row)
(1 row)
continue
* * modify session.t to btree on a;
commit;
Executing . . .
(2 rows)
continue
* * * select count(*) from session.t
where a = 'a' and b = 'b' and c = 'c' and d != 5.0;
commit;
Executing . . .
+-------------+
|col1 |
+-------------+
| 1|
+-------------+
(1 row)
continue
* * modify session.t to btree on a,b;
commit;
Executing . . .
(2 rows)
continue
* * * select count(*) from session.t
where a = 'a' and b = 'b' and c = 'c' and d != 5.0;
commit;
Executing . . .
E_OP0082 consistency check
- unexpected exception occurred
Associated error messages which provide more detailed information
about
the problem can be found in the error log (errlog.log)
(Wed Jun 5 11:54:33 2002)
continue
* * * select count(*) from session.t
where a = 'a';
commit;
Executing . . .
+-------------+
|col1 |
+-------------+
| 1|
+-------------+
(1 row)
continue
* Ingres Version II 2.6/0201 (su4.us5/00) logout
Wed Jun 5 11:54:33 2002
From the error log.
[34820 , 01a9e100]: Wed Jun 5 11:54:33 2002 Segmentation
Violation (SIGSEGV) oph_temphist(0x194778) @ PC 194884 SP
fd62f730 PSR fe001003 G1 0 o0 8d1160
[34820 , 01a9e100]: Stack dump pid 9783:
FD62F730: oph_catalog(FD62FDFC,00000000,01A35B60,FD62F8A0,FFFFFFF8
,FD62F8A8)
FD62F790: oph_composites(01A35BA0,FD62F944,02000000,00000000,00000
000,01A34FA8)FD62F8E0:
oph_histos(01A35BA0,00195000,00000000,01A34FA8,01A345A4, 01A34FA8)
FD62FA00: opn_enum(01A35BA0,00000004,00000010,01A35148,00000004,00
000001)
FD62FAA0: opj_enum(01A35BA0,FD62FB80,00004000,FFFFFFFF,FD62FDFC,01
A33F58)
FD62FB68: opj_joinop(FD6300B8,00000000,FD62FC5C,00000001,00000003,
0015029C)
FD62FC00: ops_statement(FD62FDFC,02063B80,FD63021C,FD63020C,000000
00,FD62FDFC)
FD62FC60: ops_dbprocedure(FD62FDFC,02063B80,005FC400,00000004,01A1
2060,006B40E8)
FD62FCC0: ops_sequencer(FD62FDFC,02063B80,00095C00,00549874,000000
00,01A00068)
FD62FD20: opf_call(01AA0B30,0013B964,00000000,01AA114C,01AA0E78,01
A391E0)
FD630388: scs_sequencer(00000005,01AA0B30,01AA114C,0053367C,FFFFFF
FF,FD631AEC)
FD630450: CSMT_setup(00000000,00000000,01A9E178,40FBFFFE,FD631E14,
FD631E04)
FD631AF0: FF1DB6E0(01A9E100,FF1EF690,00000001,00000001,FF1EE000,00
000000)
FD631D10: CSMT_setup(01A9E100,00000000,00000000,00000000,00000000,
00000000)
[34820 , 01a9e100]: Wed Jun 5 11:54:33 2002
E_OP0082_UNEXPECTED_EX
consistency check
- unexpected exception occurred
Associated error messages which provide more detailed information about
the problem can be found in the error log (errlog.log)
Karl & Betty Schendel
>
>I am in the process of moving a client's operations from 6.4 to 2.6.
>select based the columns of the key, an E_OP0082 consistency check
>error is generated. The below sample and results from the errlog
>illustrates the problem.
>
>Can anyone suggest a possible cause and solution? The OS is
>Solaris 8 and the Ingres is 2.6 off the CD.
This sounds like one of the bugs caused by the 2.5 model histogram code.
You'll need a patch. There are no public patches for 2.6 yet, as you
found out, but I should think that Tech Support could provide you with
a patch to fix it.
If there is a permanent table named t, you might work around the bug
by calling your session table something other than session.t. If that
isn't the case, you are probably stuck until you get a patch.
--
Karl R. Schendel, Jr. sche...@kbcomputer.com
K/B Computer Associates www.kbcomputer.com
Ingres, Unix, VMS Consulting and Training
Stefan Lindner
available patch):
"(GENERIC)
If you create a Global Temporary Table with the same name but a
different structure to an existing permanent table, then attempts
to use the table will cause E_OP0082 errors and a SIGSEGV in
opc_keyqual in the error log.
Bug is refixed. Original fix disabled 2.5 "model histograms for
global temporary tables" feature.
(104342)"
"Marvin Hubenthal" <mhub...@sophistry.com> schrieb im Newsbeitrag
news:3CFE59...@sophistry.com...
Graham Jakins
We had the same problems when installing Ingres 2.5 and needed a patch,
which there were no public patches for either.
We also found that a consistency check still occurred after the patch was
installed - and was resolved by increasing the stack_size (thanks to CA tech
support).
Before upgrading to either 2.5 or 2.6 it is a _MUST_ to contact CA Tech
Support and ask for the latest patch available. It will save a lot of time
in the long run.
Graham Jakins
Lotteries Commission of Western Australia
Marvin Hubenthal
>
> I am in the process of moving a client's operations from 6.4 to 2.6.
> In the process I would like to take advantage of some of the newer
> features available, one being global temporary tables. In doing so,
> I hit a problem. When I have a key of more than one column and
> select based the columns of the key, an E_OP0082 consistency check
> error is generated. The below sample and results from the errlog
> illustrates the problem.
>
> Can anyone suggest a possible cause and solution?
>
I wish to thank all for replying. The sample used "session.t" which
is unique and since the orginal application code, which I modified,
created a permanent table (for the duration of the session), it too
would need to be unique.
I have logged a support call and will see where that leads.