Hi All,

Why are my programmers so invetive?

I have a Linux box running:
II 9.2.0 (a64.lnx/143)NPTL + 13695

It has a vnode (call it XX) pointing to a windows platform running:
II 9.2.0 (int.w32/143) + 13595

On the Linux box, we create a distributed database and register a table
using the XX vnode. Something like...
sql bowtest_ddb/star << SQL_END
register table xx_rel from iirelation with node='XX', database='iidbdb',
dbms='INGRES'
\p\g
SQL_END

We now do...
sql bowtest_ddb/star << WEIRD_SHIT
select count(*) from xx_rel\g
select count(*) from xx_rel where 1=1\g
select count(*) from xx_rel\g
\q
WEIRD_SHIT

The first query works.

The second query produces:
E_GC2210_LCL_ABORT Session failure: Local ABORT condition.
E_RQ0042 Preceding message is from LDB=iidbdb, NODE=XX, DBMS=ingres
E_QE0545 RQF detected the loss of an LDB association.
E_QE0545 RQF detected the loss of an LDB association.

The third query (identical to the first) now produces errors as per the
second query.

I've tried using a vnode which points to another Linux installation and
the weird stuff doesn't happen.

I've tried using a vnode which points to a VMS installation and we get
the same errors. The VMS installation was running II 2.6/0401
(axm.vms/00) + 10822

Anyone got any ideas?

Martin Bowes

That was a mis-spelling.

I meant: programmers so inventive.

Not: programmers so invective.


Marty

-----Original Message-----
From: Martin Bowes [mailto:martin.bowes (AT) ctsu (DOT) ox.ac.uk]
Sent: 06 April 2010 12:35
To: Ingres and related product discussion forum
Subject: [Info-Ingres] where 1=1 weirdness in the STAR chamber

Hi All,

Why are my programmers so invetive?

I have a Linux box running:
II 9.2.0 (a64.lnx/143)NPTL + 13695

It has a vnode (call it XX) pointing to a windows platform running:
II 9.2.0 (int.w32/143) + 13595

On the Linux box, we create a distributed database and register a table
using the XX vnode. Something like...
sql bowtest_ddb/star << SQL_END
register table xx_rel from iirelation with node='XX', database='iidbdb',
dbms='INGRES'
\p\g
SQL_END

We now do...
sql bowtest_ddb/star << WEIRD_SHIT
select count(*) from xx_rel\g
select count(*) from xx_rel where 1=1\g
select count(*) from xx_rel\g
\q
WEIRD_SHIT

The first query works.

The second query produces:
E_GC2210_LCL_ABORT Session failure: Local ABORT condition.
E_RQ0042 Preceding message is from LDB=iidbdb, NODE=XX, DBMS=ingres
E_QE0545 RQF detected the loss of an LDB association.
E_QE0545 RQF detected the loss of an LDB association.

The third query (identical to the first) now produces errors as per the
second query.

I've tried using a vnode which points to another Linux installation and
the weird stuff doesn't happen.

I've tried using a vnode which points to a VMS installation and we get
the same errors. The VMS installation was running II 2.6/0401
(axm.vms/00) + 10822

Anyone got any ideas?

Martin Bowes


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

This looks like bug 122893. It's fixed in p13695 but not p13595 - to be
honest I would have expected you not to hit the problem unless it was
the other way around.

Worth raising an issue.

I've just check ESD and have checked the documentation on the latest
windows patches. The bug is not listed in either windows patch 13735
(9.2.1) or 13664(9.2.0).

Marty

-----Original Message-----
From: Paul Mason [mailto:Paul.Mason (AT) ingres (DOT) com]
Sent: 06 April 2010 13:07
To: Ingres and related product discussion forum
Subject: Re: [Info-Ingres] where 1=1 weirdness in the STAR chamber

This looks like bug 122893. It's fixed in p13695 but not p13595 - to be
honest I would have expected you not to hit the problem unless it was
the other way around.

Worth raising an issue.



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

I wrote that in haste whilst I was on my way out to lunch. As I said it
would make more sense being that bug if the patches were the other way
around - which is why I advised raising an issue.

Having returned from lunch and played with your testcase I'm not now
convinced it is the same bug.

I see you've raised an issue - I'll let Mr Dyer know.