Not sure if anyone else has noticed, but Ingres 10, unlike its
predecessors, allows duplicate rows in the iirelation system catalog.

When I asked Actian Tech. Support why this was, I was told that it
improves performance.
And the reason why I asked them was because I have had to open Issue
on the back of a situation where one of our Ingres 10 databases ended
up with a couple of duplicate rows in iirelation!

Actian say that duplicates should never happen. And I say that
duplicates would never have happened if duplicates had not been
allowed!

So here's my Friday question - has anyone else seen duplicates in
iirelation (iitables) since running Ingres 10 ?

What character set are you using?
Regards,
Ian

-----Original Message-----
From: info-ingres-bounces (AT) kettleriver...ting (DOT) com
[mailto:info-ingres-bounces (AT) kettleriverconsulting (DOT) com] On Behalf Of
rthdavid
Sent: 28 October 2011 15:01
To: info-ingres (AT) kettleriverconsulting (DOT) com
Subject: [Info-Ingres] Duplicate rows in iirelation

Not sure if anyone else has noticed, but Ingres 10, unlike its
predecessors, allows duplicate rows in the iirelation system catalog.

When I asked Actian Tech. Support why this was, I was told that it
improves performance.
And the reason why I asked them was because I have had to open Issue
on the back of a situation where one of our Ingres 10 databases ended
up with a couple of duplicate rows in iirelation!

Actian say that duplicates should never happen. And I say that
duplicates would never have happened if duplicates had not been
allowed!

So here's my Friday question - has anyone else seen duplicates in
iirelation (iitables) since running Ingres 10 ?
_______________________________________________
Info-Ingres mailing list
Info-Ingres (AT) kettleriverconsulting (DOT) com
http://ext-cando.kettleriverconsulti...fo/info-ingres

On Oct 28, 2011, at 10:00 AM, rthdavid wrote:

Support's answer is a slight mis-translation of the actual situation.

I was the guy who turned off duplicate row checking in the definition of
iirelation, because all of the internal DMF calls that affect iirelation
*already* had the flag set that says "don't bother with duplicate row checking".
So the table-definition request for duplicate row checking was bogus and
misleading. There shouldn't be any performance improvement that
I can think of.

If there is or was some mystery path through DMF that could potentially
insert duplicate rows into iirelation WITH duplicate-row checks
enabled, that is by my definition a bug, and the Ingres 10 change has
simply exposed it. I know of no such path. (If there is one, my guess is
that it would be related to crash recovery; but that is just a guess.)

In other words, if you are seeing duplicate rows in iirelation that didn't
happen pre-10, there must have been TWO bugs: one, the attempt to
insert duplicate rows, and two, actually checking for the duplicates
in violation of the usual flags. It wouldn't be the first time that multiple
bugs have cancelled, but I'd like to see more evidence before concluding
that it's the case here.

Duplicates should never be attempted in iirelation, period. If that
happens, the attempt is a bug. And, I would expect that the same
duplicates would occur in older versions, because they do iirelation
operations with the "don't do duplicate checking" flag turned ON.

Or any older version, for that matter?

Karl

Hi Karl,
Any chance that this could happen with UTF8? If there are any direct,
raw compares involved on a hypothetical code path then we might match
due to collations being used elsewhere - 10.0 still has Unicode
collation. In Unicode for instance 'x_x' == 'xx'.
Regards,
Ian

-----Original Message-----
From: info-ingres-bounces (AT) kettleriver...ting (DOT) com
[mailto:info-ingres-bounces (AT) kettleriverconsulting (DOT) com] On Behalf Of Karl
Schendel
Sent: 28 October 2011 15:45
To: Ingres and related product discussion forum
Subject: Re: [Info-Ingres] Duplicate rows in iirelation


On Oct 28, 2011, at 10:00 AM, rthdavid wrote:

Support's answer is a slight mis-translation of the actual situation.

I was the guy who turned off duplicate row checking in the definition of
iirelation, because all of the internal DMF calls that affect iirelation
*already* had the flag set that says "don't bother with duplicate row
checking".
So the table-definition request for duplicate row checking was bogus and
misleading. There shouldn't be any performance improvement that
I can think of.

If there is or was some mystery path through DMF that could potentially
insert duplicate rows into iirelation WITH duplicate-row checks
enabled, that is by my definition a bug, and the Ingres 10 change has
simply exposed it. I know of no such path. (If there is one, my guess
is
that it would be related to crash recovery; but that is just a guess.)

In other words, if you are seeing duplicate rows in iirelation that
didn't
happen pre-10, there must have been TWO bugs: one, the attempt to
insert duplicate rows, and two, actually checking for the duplicates
in violation of the usual flags. It wouldn't be the first time that
multiple
bugs have cancelled, but I'd like to see more evidence before concluding
that it's the case here.

Duplicates should never be attempted in iirelation, period. If that
happens, the attempt is a bug. And, I would expect that the same
duplicates would occur in older versions, because they do iirelation
operations with the "don't do duplicate checking" flag turned ON.

Or any older version, for that matter?

Karl



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

I think the name compares in dmu create use MEcmp rather than
collation compares, but I couldn't rule it out completely without a code audit.

I do believe that I've seen duplicate iirelation rows in a database before, but
it was a long time ago (2.6 or older), and it was after a buggered-up crash
recovery attempt that went completely south. I don't remember the details
any more.

Karl

On Oct 28, 2011, at 10:52 AM, Ian Kirkham wrote:

I took on board Karl's comments, and I now suspect that the most
likely reason for duplicate rows in iirelation was due to a failed
(and silent) database recovery on installation startup.

An 'inglogs' has been taken and sent to Actian Support to further the
investigation.