Oninit® Logwalker — --group-by-xid output

The HUMAN mode emits one line per log record in the order the engine wrote them. That order interleaves transactions: BEGIN of tx 31 might be followed by BEGIN of tx 39, then HINSERT for 31, then HINSERT for 39, and so on. To read the log as a sequence of transactions rather than a sequence of records, use --group-by-xid: it wraps the per-record content with explicit framing markers at every BEGIN and at every COMMIT / ROLLBACK so each transaction is visually delimited.

xid is not unique across a log. Informix recycles xid values after a transaction commits or rolls back, so the same xid can identify several distinct transactions in one log. The framing markers handle this explicitly: the second time a given xid value starts a transaction, the BEGIN frame is tagged (xid REUSED) so the reader sees that this is a new transaction even though its xid value is one we’ve seen before.

Invocation

$ logwalker -n 271 -m 12 --group-by-xid

Output

# logwalker v0.6.0 — uniqid=271  extents=1  total_pages=5000
#   extent[0]: chunk=1 path=/home/informix/data/rootdbs byte_off=0x3157800 pagesize=2048 n_pages=5000
[logwalker] catalog: 2104 named partitions loaded (tables + indexes) from sysmaster.

--- TX 31 BEGIN @ LSN 271:0x18 ---
LSN 271:0x00000018  xid=31      BEGIN transaction (pid=26847, started 2026-05-06 01:00:06)
LSN 271:0x00000050  xid=31      UNIQID — reserved next serial 883 for testdb.syssurrogateauth
LSN 271:0x00000080  xid=31      INSERT into testdb.syssurrogateauth (rowid 0x00000101, 169 bytes)
LSN 271:0x0000016c  xid=31      ADDITEM — index entry on testdb.syssurrogateauth_pk for rowid 0x001007ef
LSN 271:0x000001ac  xid=31      UNIQID — reserved next serial 884 for testdb.syssurrogateauth
LSN 271:0x000001dc  xid=31      INSERT into testdb.syssurrogateauth (rowid 0x00000102, 169 bytes)
LSN 271:0x000002c8  xid=31      ADDITEM — index entry on testdb.syssurrogateauth_pk for rowid 0x001007ef
LSN 271:0x00000308  xid=31      COMMIT at 2026-05-06 01:00:06
--- TX 31 COMMITTED @ LSN 271:0x308 ---

--- TX 31 BEGIN @ LSN 271:0x1018  (xid REUSED) ---
LSN 271:0x00001018  xid=31      BEGIN transaction (pid=26847, started 2026-05-06 01:00:06)
LSN 271:0x00001050  xid=31      UNIQID — reserved next serial 885 for testdb.syssurrogateauth
LSN 271:0x00001080  xid=31      INSERT into testdb.syssurrogateauth (rowid 0x00000103, 168 bytes)
LSN 271:0x00001168  xid=31      COMMIT at 2026-05-06 01:00:06
--- TX 31 COMMITTED @ LSN 271:0x1168 ---

xid reuse, in detail

The output above shows two distinct transactions that both happen to use xid 31:

• First transaction (frame 0x18 → 0x308): inserts two rows, two ADDITEMs, two UNIQIDs, then commits. Frame footer is TX 31 COMMITTED @ LSN 271:0x308.
• Second transaction (frame 0x1018 → 0x1168): inserts one more row, then commits. Frame header is tagged (xid REUSED) — logwalker has already seen a BEGIN with xid=31 in this walk, so this BEGIN is flagged as a new transaction reusing the value.

The (xid REUSED) marker is the answer to "is this still the same transaction?" without having to walk the link chain. If you spot two records with the same xid but separated by a --- TX <xid> COMMITTED --- footer between them, they belong to different transactions even though the xid is identical.

Frame markers

Composing with --decode-rows

The two flags compose. Running --group-by-xid --decode-rows emits transaction-grouped output with each row-shaped record decoded into (col=val) pairs from the catalog where the column metadata is reachable. This is the most readable shape for an audit / incident-review session.