One subscription’s identity and terms, as stored — everything but the
primary key (subscriber_type, key) itself, which the caller already
knows from its own lookup.
Ceiling on the rows a single backfill page read may return, and the width
of a gap-fill stall episode’s window (an episode’s re-read is a page read,
so one episode covers what one page read can see).
How many groups the commit-lane fold emits between sparse checkpoints. The
order is computed, so a checkpoint only bounds how far a restart or a
lagging subscriber’s backfill has to re-fold.
How long the persistent cache waits before the first gap-fill attempt
for a stalled broadcast sequence. Most gaps are in-flight transactions
that committed out of sequence-allocation order and resolve on their own
within a few ms (and this process’s own commit-failed allocations are
compensated reactively, never waiting for a fill attempt at all);
attempting immediately wastes a page re-read per gap. At high posting
rates (hundreds of sequences/s) there is nearly always an in-flight
frontier gap, so a sub-second grace is guaranteed-too-short and turns
the fill into a permanent background load — hence seconds, not
milliseconds. Attempts are read-only until the missing sequences are
provably abandoned (every transaction that could have produced them
has ended — see MailboxTables::abandonment_proof_passed), so a fill
can never collide with a live writer regardless of this setting.
How long the persistent cache goes without authoritative progress (a
newly-seen committed row or a confirmed head read) before polling the
sequence head (the O(1) last_value query). Backstops lost wake-ups: a
writer crashing between commit and notify, a dead remote notifier, or
external writers that never notify.
How long the per-process notifier coalesces committed-batch reports
before emitting one pg_notify wake-up hint. Notify-bearing commits
serialize on a cluster-wide lock, so app transactions no longer notify;
this bounds the added cross-process wake-up latency (in-process delivery
is unaffected).
How often the partition maintainer wakes to pre-create partitions ahead of
the head. Each tick is idempotent (CREATE ... IF NOT EXISTS), so this is
a cheap steady-state poll; premake margin, not cadence, is the safety
budget against bursts.
How many partitions ahead of the current sequence head the maintainer
keeps created — including on the initial synchronous ensure at
registration, so a fresh install starts with a multi-partition runway
(the migration itself ships only p0 + DEFAULT). premake * width must
comfortably exceed the events produced between two maintainer ticks so the
head never reaches the last pre-made boundary (which would spill into the
DEFAULT partition). Empty partitions are cheap, so this errs generous:
5 * 2M = 10M sequences of headroom by default.
One page/batch of decoded persistent rows: each item is one committed
sequence position — Ok for a decoded event or a placeholder, Err
for a stored payload that does not decode into P.