Oninit® Logwalker — Output Examples

Logwalker emits three output shapes; pick the one that matches how you’re going to read the log. All three modes walk the same chunk bytes via the read-only O_RDONLY + pread() path and only differ in how they format what they find.

Three modes at a glance

Live samples

• Default HUMAN output — LSN-prefixed plain-English lines, with and without --decode-rows.
• --compat onlog output — legacy 6-column form for existing tooling.
• --group-by-xid output — transaction-framed, with explicit handling for xid reuse.

These three are output shapes. Object-track (-t / --table) is a selection that composes with any of them — report every change to one table across a range of logs. In HUMAN and --group-by-xid form a track walk also frames each matched transaction with its boundary, so an INSERT with no COMMIT (or a ROLLBACK) is never mistaken for a durable change; see Transaction boundaries in track mode.

Worked output — SQL & DDL reconstruction

The --extract-spl and --extract-ddl flags add an end-of-walk summary that rebuilds the statements behind the catalog changes (full detail on the SQL & DDL Reconstruction page). A procedure comes back from its sysprocbody text rows:

$ logwalker -n 480661 --extract-spl

=== Reconstructed SQL/SPL (from sysprocbody text rows) ===
--- coris procid=1073 (raise_salary)  [2 text row(s)] ---
create procedure raise_salary(p_empno int, p_pct decimal(5,2))
   define v_old decimal(10,2);
   select salary into v_old from employee where empno = p_empno;
   update employee set salary = v_old * (1 + p_pct/100) where empno = p_empno;
end procedure;

Table DDL is synthesized from the catalog rows — a fresh CREATE TABLE with its index, and a later DROP:

$ logwalker -n 480661 --extract-ddl

=== Reconstructed DDL (from system-catalog inserts) ===
--- TABLE coris.informix.orders (tabid=500)  [3 column(s)] ---
create table orders (
    orderno              serial,
    custid               integer,
    odate                date
);

--- INDEX coris.idx_ord_cust (tabid=500) ---
create unique index idx_ord_cust on orders (custid, orderno desc);

--- DROP trigger coris.trg_old_audit ---
drop trigger trg_old_audit;

An ALTER TABLE on an existing table is told apart from a fresh CREATE (the systables row is updated, not inserted) and rendered as its ADD / MODIFY / DROP column forms — each column’s catalog type code formatted back into its SQL type:

=== Reconstructed DDL (from system-catalog inserts) ===
--- TABLE coris.informix.account (tabid=600)  [alter] ---
alter table account add (iban char(34), opened date);
alter table account modify (balance money(16,2));
alter table account drop (notes);

xid is not unique

A subtle property of Informix logical logs that all three modes acknowledge in different ways: the xid (transaction id) is recycled after a transaction completes. The same numeric value can identify several distinct transactions in a single log. The HUMAN and --compat onlog modes report xid as-is and trust the reader to track frame boundaries from BEGIN / COMMIT records; --group-by-xid handles it explicitly with the (xid REUSED) tag on later BEGINs. Don’t use raw xid matching to deduplicate — always pair it with the BEGIN’s LSN.

Common environment

All three example pages capture the same 12-record window from log uniqid 271 of a development Informix instance: two short single-row INSERT transactions on the same table, both happening to use xid 31 (the second a reuse). The captured records are real; the LSN values, addresses, partnums, and timestamps come from a verified walk.