[Info-ingres] unloaddb sigsegv
Martin Bowes
martin.bowes at ndph.ox.ac.uk
Wed Apr 25 09:24:16 UTC 2018
Hi All,
On Ingres II 10.2.0 (a64.lnx/100) +p15151
Fortunately on a development database, an attempt to unloaddb will be greeted with a sigsegv
unloaddb -ulust bow_ldbc
INGRES UNLOADDB Copyright 2014 Actian Corporation
Unload directory is '/user/ingres/bow_ldbc'.
Reload directory is '/user/ingres/bow_ldbc'.
There are 7 sequences in the database.
There are 2067 tables in the database.
There are 125 views in the database.
There are 43 synonyms in the database.
There are 0 events in the database.
There are 1595 procedures in the database.
There are 2371 rules in the database.
Exiting . . .
due to Segmentation Violation (SIGSEGV) @PC 0000003a89e7f5c0
RSP 00007ffd9e4f8f08 RBP 00007ffd9e4f9160 RSI 0000000000000428
RDI 00000000014d4752 RAX 00000000014d4761 RBX 00007ffd9e4f9030
RCX 0000000000000000 RDX 00000000014d4761
Please contact your Technical Support representative.
Segmentation fault (core dumped).
The error log just repeated the sigsegv details with no extra information.
After some experimentation with copydb we found the problem would only occur if we included the constraints on a particular table, c_program_params.
After further work with rollforwarddb we found the problem was reported as:
Wed Apr 25 09:30:11 2018 E_DM9607_DMVE_DEL Error recovering DELETE operation.
Wed Apr 25 09:30:11 2018 E_DM1306_RFP_APPLY_RECORD Error occurred attempting to apply rollforward record.
LSN=(571729BF,76BEC90C), COMP_LSN=(00000000,00000000), DBID=0x5A96A412, XID=0x0000571775956D9F
DEL Length: 382 Flags: JOURNAL,CRHEAD
Using auditdb -all we found:
LSN=(571729BF,76BEC90C), COMP_LSN=(00000000,00000000), DBID=0x5A96A412, XID=0x0000571775956D9F
DEL Length: 382 Flags: JOURNAL,CRHEAD
TABLE: (20,0) TID: [1381,17] SIZE: 262
Table 20, 0 is iiqrytext.
So we recovered until just before the nasty bit and using the tid we find:
select tid/512 as page, mod(tid, 512) as row, * from iiqrytext where tid/512= 1381
┌──────────────────────┬──────┬─────────────┬─────────────┬─────────────┬─────────────┬─────────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│page │row │txtid1 │txtid2 │mode │seq │status │txt │
├──────────────────────┼──────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ 1381│ 16│ 830472192│ -1073741824│ 19│ 0│ 2│grant update on "lust".c_object_name to group cryogenics_group │
│ 1381│ 18│ 830472192│ -939524096│ 19│ 0│ 2│grant select on "lust".c_object_name to user biotek │
So if I'm interpreting these results correctly it looks like a constraint definition at row 17 on page 1381.
Anyone like to make a guess at how this could occur?
Martin Bowes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.planetingres.org/pipermail/info-ingres/attachments/20180425/686cd6d0/attachment.html>
More information about the Info-ingres
mailing list