Ingres Community Forums Login Register Ingres.com  

Ingres Community Forum


Go Back   Ingres Community Forums > Community > Newsgroups & Mailing Lists > Comp.Databases.Ingres
 

Reply
 
LinkBack Thread Tools Display Modes
Old 2009-06-29   #1 (permalink)
Martin Bowes
Guest
 
Posts: n/a
Default Re: [Info-Ingres] hash partiton,seconday indicies and SIGSEGV...Urgent!

Hi Karl,

We have a single server...not a sole server.

I chose the hash partition as there is no obvious range to check on. But
I might just have choked on that as well. I suppose I could drop the
stats for one of the columns to disk and use that to make a reasonable
stab at setting up some range values.

And the only reason I'm partitioning this table is to get a lot more
blob support tables created. This works around the current bug of the
bloody thing stopping when the initial iietab fills up.

The other alternative being to configure a 16K cache and modify the blob
support table to use that page size.

Marty

-----Original Message-----
From: info-ingres-bounces@kettleriverconsulting.com
[mailto:info-ingres-bounces@kettleriverconsulting.com] On Behalf Of Karl
& Betty Schendel
Sent: 29 June 2009 11:05
To: Ingres and related product discussion forum
Subject: Re: [Info-Ingres] hash partiton,seconday indicies and
SIGSEGV...Urgent!
Importance: High


On Jun 29, 2009, at 5:33 AM, Martin Bowes wrote:

> II 9.0.4 (a64.lnx/105)NPTL + p12707
>
> Over the weekend I altered a table which has several long varchar
> columns to be hash partitioned 10 ways. The hash key was the same
> as the btree unique key of the table.
>
> [snip]
>
> The table has two persistent indexes named gobz_gtyp_status,
> gobz_pid_gtyp.
>
>
>
> Since the modify, any attempt to insert into the table will crash
> the server with a SIGSEGV.
>


Bummer that we can't get the stack trace. Were you running multiple
DBMS servers?

I can't stay that I recall a segv bug quite like this one.

It is a bit odd to be using hash partition with a btree primary key
structure.
That implies that any sort of range scan will have to probe each
partition,
and I'm pretty sure that OPF will end up degenerating anything other
than
equality lookups into table scans. (It might compile a range scan
for each
partition, but you wouldn't be getting rows out in order.) Typically
you'd use range partitioning with btree, or hash partitioning with
hash table structures. I don't see how any of this would cause a
segv upon insert, though.

Karl


_______________________________________________
Info-Ingres mailing list
Info-Ingres@kettleriverconsulting.com
http://www.kettleriverconsulting.com...fo/info-ingres


  Reply With Quote

Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


© 2009 Ingres Corporation. All Rights Reserved