Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[Info-Ingres] hash partiton, seconday indicies and SIGSEGV...Urgent!

72 views
Skip to first unread message

Martin Bowes

unread,
Jun 29, 2009, 5:33:41 AM6/29/09
to Ingres and related product discussion forum

Hi All,

 

II 9.0.4 (a64.lnx/105)NPTL + p12707

 

As a matter of some urgency….

 

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.

 

modify gobz to btree unique on

    trid, cid

with

    page_size = 8192,

    partition = (hash on trid, cid

    partition gobz_pp1 with location=(ii_database_6),

    partition gobz_pp2 with location=(ii_database_7),

    partition gobz_pp3 with location=(ii_database_8),

    partition gobz_pp4 with location=(ii_database_9),

    partition gobz_pp5 with location=(ii_database_10),

    partition gobz_pp6 with location=(ii_database_6),

    partition gobz_pp7 with location=(ii_database_7),

    partition gobz_pp8 with location=(ii_database_8),

    partition gobz_pp9 with location=(ii_database_9),

    partition gobz_pp10 with location=(ii_database_10)

    )

 

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.

bb4.ctsu::[38876           , aae40200]: Mon Jun 29 09:53:55 2009 Segmentation Violation (SIGSEGV) @PC 00002b9e6a1fc4b2

RSP 0000000040895aa0  RBP 000000000000000d  RSI 00002b9e8cca1288

RDI 00002b9e8cca1288  RAX 0000000000000000  RBX 00002b9e8cf5c198

RCX 00002b9e8cc9ff10  RDX 0000000000000000

 

-----------BEGIN STACK TRACE------------

Exception in stack unwind

Trying again without symbols

Exception in stack unwind

-----------END STACK TRACE----------

bb4_ctsu::[38876             , 00002aaaaae40200]: Mon Jun 29 09:53:55 2009 E_SC0221_SERVER_ERROR_MAX    Error count for server has been exceeded.

bb4_ctsu::[38876             , 00002aaaaae40200]: Query:  EXECUTE e0 using ~V , ~V , ~V , ~V , ~V , ~V , ~V , ~V , ~V , ~V , ~V , ~V , ~V , ~V , ~V , ~V , ~V , ~V , ~V , ~V , ~V , ~V , ~V ^@

bb4_ctsu::[38876             , 00002aaaaae40200]: LQuery: PREPARE e0 FROM INSERT INTO gobz (cid,trid,xu_hid,aid,rid,xu_ts,xu_at,xu_ca,chain,author,tsig,pver,xu_chk,xu_flag,pid,gtyp,xb_outr,xb_innr,status,xu_ovalid,xub_osr,xu_ivalid,xub_isr) VALUES ( ? , ? , ? , ? , ? , ? , ? , ? , ? , ? , ? , ? , ? , ? , ? , ? , ? , ? , ? , ? , ? , ? , ? )^@

 

Sometimes the log shows…

bb4_ctsu::[49132             , 00002aaaaba12200]: Mon Jun 29 09:25:05 2009 E_DM9C02_MISSING_TCB_INFO    TCB information was missing. Page 12584 in table 243,-2147477243 of database ace_pack_live did not have the required Table Control Block information for its secondary indexes.

bb4_ctsu::[49132             , 00002aaaaba12200]: Mon Jun 29 09:25:05 2009 E_DM9C03_INDEX_TCB_INFO  TCB information exists for secondary index gobz_gtyp_status (243,6456), in database ace_pack_live.

bb4_ctsu::[49132             , 00002aaaaba12200]: Mon Jun 29 09:25:05 2009 E_DM9C03_INDEX_TCB_INFO  TCB information exists for secondary index gobz_pid_gtyp (243,6455), in database ace_pack_live.

bb4_ctsu::[49132             , 00002aaaaba12200]: Mon Jun 29 09:25:05 2009 E_DM9449_DMD_CHECK   DMD_CHECK called from file /devsrc/ingresr30/b105/src/back/dmf/dmp/dm0p.c line 14299.

Exception in stack unwind

bb4_ctsu::[49132             , 00002aaaaba12200]: Mon Jun 29 09:25:05 2009 E_DM9300_DM0P_CLOSE_PAGE Buffer still fixed.

 

I've tried dropping and recreateing the secondary indicies…No good.

I've tried just dropping the secondary indicies…No good.

I'm now going to rebuild the table with nopartitions and see if that solves the problem.

 

The rebuild will take about 3-4 hours…In the mean time does anyone have a suggestion as to what might be causing the problem.

 

Martin Bowes

 

Karl & Betty Schendel

unread,
Jun 29, 2009, 6:04:57 AM6/29/09
to Ingres and related product discussion forum

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


Martin Bowes

unread,
Jun 29, 2009, 6:29:49 AM6/29/09
to Ingres and related product discussion forum
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

Karl


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


Martin Bowes

unread,
Jun 29, 2009, 8:16:20 AM6/29/09
to Karl & Betty Schendel, Ingres and related product discussion forum
Hi Karl,

> >
> > 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.

> Which it may not, unless someone has fixed it. When I hooked up
> partitioning to blobs, my intent was to put each partition's blob
> segments in separate etabs. And yes, it does create an etab for
> each partition ... and then proceeds to put all the blob data into
> etab zero! (oops)

Yes its still doing that, but my testing shows that its quite happy to
roll onto the next iietab, but it will generate errors in the errlog at
each change, these seem to be spurious.

Marty

PS. Ive now restored the table to non partitioned and recreated the
indicies and now the insert runs w/out error.


Ingres Forums

unread,
Jul 1, 2009, 2:34:25 AM7/1/09
to

Marty,

This is almost certainly a bug (and a prety serious one at that), can
you create an issue for it so we can track it down.


--
stephenb
------------------------------------------------------------------------
stephenb's Profile: http://community.ingres.com/forum/member.php?userid=175
View this thread: http://community.ingres.com/forum/showthread.php?t=10876

0 new messages