[Info-ingres] qe90, star and a seriously bad day at the office

[Martin Bowes]

Hi All.

Hands up everyone who knew that running a qe90 in star was not a good idea.

Keep your hands up if you knew that an error indicating this would be printed into II_STAR_LOG ... if you had that configured.
Something like:
!Thu Nov 29 11:30:31 2018 [25658,81A75F00] ace_trexy_ddb >>>>>  set trace point qe90
!TPF 00000000019B0230: QE90 will crash the server before executing
!TPF 00000000019B0230:    the loop to log and commit the next state
!TPF 00000000019B0230:    of DX 5BFFC9FE 000E79EB.

Keep your hands up if you knew that no such message would be delivered to the front end where you might notice it.

Now for the top of the class...it's quite a funny story when you get past the tragic elements and overriding sense of doom.
In your distributed database create a work table which we use to insert into the registered table...
create table work(
    a integer4 not null not default,
    b integer4 not null not default
) with nojournaling;

insert into work values (5,1);
insert into work values (5,2);
insert into work values (5,3);
insert into work values (5,4);
insert into work values (5,5);

set qep;
set trace point qe90;
\p\g
insert into test (a, b, tinsert)
select a, b, date('19-Nov-2018 12:00:00')
from work;
\p\g
commit;
\p\g
\q

Now  the star server crashes...
and leaves an uncommitted transaction in the log.
That transaction is holding a table level lock, which meant I had to reformat the friggen log file, recover my 140G database from backup and replay lots of dumps and journals.

I was very unhappy.

FYI. lartool can actually remove the transaction from the log. Pity I thought about that after the recovery was started.

Martin Bowes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.planetingres.org/pipermail/info-ingres/attachments/20181130/a7ef1ebb/attachment.html>