Hi All,



I'm running II 9.0.4 (a64.lnx/105)NPTL + 12707. On this installation I
have recently hash partitioned a btree table, creating 10 partitions.
Since then any attempt to insert into the table fails. Furthermore, it
crashes the server with a SIGSEGV in QEF.



The table has two secondary indices. I left those as persistent
indexes...which is not a good move, but I don't think it has any bearing
on the problem.



It sorta looks like Bug 115816 (GENERIC), but the patch notes insist
this was fixed 12707.

Updates of a secondary index on a partitioned table were not being done
properly, resulting in incorrect tids in the secondary index. This would
be most likely to happen if the base table were compressed (so that rows
could move without index key changes.) Symptoms range from incorrect
data retrieved, to E_US1265 errors, to SEGV's in QEF or DMF.



As this was a production database I had to unpartition the table pretty
damn quick smart...well as much as a two hour modify is quick...



Since then I have tried to repeat the problem elsewhere with no success.
I have copied as many as 10000 rows from the table to the test database
and tried inserts which appear to have no problems whatsoever. The
production table has 1874112 rows.



So before I go and start the process of trying to copy even more rows
from the production case...has anyone seen anything like this and have
any suggestions?



Martin Bowes

On Mar 2, 2009, at 10:05 AM, Martin Bowes wrote:

Doesn't sound familiar. Are there any rules on the table in production?
Was it regular btree, or btree key and/or data compressed?

Two hours to modify a puny little 2 million row table? Surely that's
not right??? Are you emulating a64 on a Z-80, or what? :-)

Karl

Hi Karl,

Regular btree, no compression.

There are 5 rules....and that seems to be the key.
I just recovered the database to the recovery host, partitioned the
table, made the secondary indicies non persistent and ran a dummy insert
and update on the table.
The insert worked but the update produced a SIGSEGV in the errlog and
E_SC0206 at the front-end. A subsequent attempt crashed the server.

I repeated with set norules and the update worked fine.

Now I can spend the rest of the day trying to make a test case that
doesn't involve 120G of data.

The table has 4 long varchar columns. I've always assumed they had a big
part to play in this. Until recently it had two persistent secondary
indicies. I've converted them to non-persistent as that makes a lot of
difference when doing a modify partition to reconstruct.

I'm also a little concerned about the cache. The table is 8k pages and
my 8k cache has 2000 single page buffers and 1000 group buffers, each
group being 8pages. The cache hit rate is 88% so I'm thinking of
expanding it to include a lot more group buffers as my GREAD/READ ratio
is 33.

Marty

Martin Bowes wrote:

Go ahead and try, but unless you can create enough group buffers to hold
the entire table you'll get just as much benefit from one group buffer.

Imagine your table fits exactly into the 1,000 existing group buffers.
The first time you scan the table it all gets loaded into those
buffers. The second time you scan, the query is satisfied entirely from
the group buffers and you get to go home early.

Now suppose your table is even 1 pages bigger. You get almost all the
way to the end of the scan, then you have to overwrite the first group
buffer to get that last page. Now you go to scan the table a second
time and the first page isn't in a group buffer. No problem; look for
the least-recently used buffer, which is the second one, and load the
first group into that. Then you go to get the next group, but you just
overwrote it. No problem; look for the least recently-used buffer,
which is the third one.... And so on; you get the idea.

--
Roy

UK Ingres User Association Conference 2009 will be on Tuesday June 9, 2009
Go to http://www.iua.org.uk/join to get on the mailing list.

Marty,

This is bug 120693, which is fixed in Ingres 9.1.x but not in 9.0.4. If
you want a patch for it open an issue and we'll get the change crossed
into 9.0.4 for you.

120693's release notes are:
(GENERIC)
E_SC0206 and stack showing qeq_part_open updating partitioned table


Robert


-----Original Message-----
From: info-ingres-bounces (AT) kettleriver...ting (DOT) com
[mailto:info-ingres-bounces (AT) kettleriverconsulting (DOT) com] On Behalf Of
Martin Bowes
Sent: 03 March 2009 12:22
To: Ingres and related product discussion forum
Subject: Re: [Info-Ingres] weirdness on partitioned table


Hi All,

Its taken a fair amount of effort, but I've managed to make a simple
test case...

I've attached a copy.in and a README.

It fails on II 9.0.4 (a64.lnx/105)NPTL patches 12707 and 13137. But is
OK on II 9.1.1 (a64.lnx/103)NPTL 13220.

If you want to try it out, be aware that if the problem exists you may
crash the installation.

Marty

Hi Robert.

Thanks for that,

I've already opened an issue on this and I'll post your reply in there.

Marty

-----Original Message-----
From: info-ingres-bounces (AT) kettleriver...ting (DOT) com
[mailto:info-ingres-bounces (AT) kettleriverconsulting (DOT) com] On Behalf Of
Robert Kibble
Sent: 03 March 2009 14:17
To: Ingres and related product discussion forum
Subject: Re: [Info-Ingres] weirdness on partitioned table

Marty,

This is bug 120693, which is fixed in Ingres 9.1.x but not in 9.0.4. If
you want a patch for it open an issue and we'll get the change crossed
into 9.0.4 for you.

120693's release notes are:
(GENERIC)
E_SC0206 and stack showing qeq_part_open updating partitioned table


Robert


-----Original Message-----
From: info-ingres-bounces (AT) kettleriver...ting (DOT) com
[mailto:info-ingres-bounces (AT) kettleriverconsulting (DOT) com] On Behalf Of
Martin Bowes
Sent: 03 March 2009 12:22
To: Ingres and related product discussion forum
Subject: Re: [Info-Ingres] weirdness on partitioned table


Hi All,

Its taken a fair amount of effort, but I've managed to make a simple
test case...

I've attached a copy.in and a README.

It fails on II 9.0.4 (a64.lnx/105)NPTL patches 12707 and 13137. But is
OK on II 9.1.1 (a64.lnx/103)NPTL 13220.

If you want to try it out, be aware that if the problem exists you may
crash the installation.

Marty

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