postgres/src/backend/access/rmgrdesc

src/backend/access/rmgrdesc/README

WAL resource manager description functions
==========================================

For debugging purposes, there is a "description function", or rmgrdesc
function, for each WAL resource manager. The rmgrdesc function parses the WAL
record and prints the contents of the WAL record in a somewhat human-readable
format.

The rmgrdesc functions for all resource managers are gathered in this
directory, because they are also used in the stand-alone pg_waldump program.
They could potentially be used by out-of-tree debugging tools too, although
neither the description functions nor the output format should be considered
part of a stable API

Guidelines for rmgrdesc output format
-------------------------------------

The goal of these guidelines is to avoid gratuitous inconsistencies across
each rmgr, and to allow users to parse desc output strings without too much
difficulty.  This is not an API specification or an interchange format.
(Only heapam and nbtree desc routines follow these guidelines at present, in
any case.)

Record descriptions are similar to JSON style key/value objects.  However,
there is no explicit "string" type/string escaping.  Top-level { } brackets
should be omitted.  For example:

snapshotConflictHorizon: 0, flags: 0x03

Record descriptions may contain variable-length arrays.  For example:

nunused: 5, unused: [1, 2, 3, 4, 5]

Nested objects are supported via { } brackets.  They generally appear inside
variable-length arrays.  For example:

ndeleted: 0, nupdated: 1, deleted: [], updated: [{ off: 45, nptids: 1, ptids: [0] }]

Try to output things in an order that faithfully represents the order of
fields from the underlying physical WAL record struct.  Key names should be
unique (at the same nesting level) to make parsing easy.  It's a good idea if
the number of items in the array appears before the array.

It's okay for individual WAL record types to invent their own conventions.
For example, Heap2's PRUNE record descriptions use a custom array format for
the record's "redirected" field:

... redirected: [1->4, 5->9], dead: [10, 11], unused: [3, 7, 8]

Arguably the desc routine should be using object notation for this instead.
However, there is value in using a custom format when it conveys useful
information about the underlying physical data structures.

This ad-hoc format has the advantage of being close to the format used for
the "dead" and "unused" arrays (which follow the standard desc convention for
page offset number arrays).  It suggests that the "redirected" elements shown
are just pairs of page offset numbers (which is how it really works).

rmgrdesc_utils.c contains some helper functions to print data in this format.