hacking.postgres.tv
./menu

postgres@hacking:~$ grep -R '#MultiXact' sessions/

#MultiXact

3 related sessions.

· 87:51 · youtube ↗

Hacking Postgres

Discuss wait-event coverage gaps; follow-up work added COPY file and program waits upstream.

Starting from an AI-assisted audit of missing wait-event coverage, the group distinguished genuine waits from CPU work and chose COPY as a testable first target. They reproduced an unreported wait in COPY FROM PROGRAM, prototyped events for program input and output, and used pg_stat_activity and pg_wait_sampling to validate them. The investigation also exposed missing coverage for ordinary COPY file reads and writes, expanding the planned patch to all four paths; the file/program work later reached core.

[timecodes · 8]
  1. AI-assisted audit of missing wait events
  2. Review discipline and excluding CPU work
  3. Choosing COPY FROM PROGRAM as the first target
  4. Reproducing the unreported external-program wait
  5. Prototyping COPY program wait events
  6. Testing COPY TO PROGRAM and separating code paths
  7. Discovering ordinary COPY file I/O gaps
  8. Validating coverage with pg_wait_sampling
#wait events#MultiXact#monitoring@Nikolay Samokhvalov@Andrey Borodin@Kirk Wolak
gap analysiscoverage PR #2COPY waits threadupstream commit
committed

direct mapping
· 71:56 · youtube ↗

MultiXact stuff

Standby MultiXact creation, corruption edges, and deadlock.

The session reproduced a standby deadlock involving MultiXact lookup: a reader holds a heap buffer lock while waiting for a not-yet-replayed MultiXact offset, and the startup process needs that buffer before it can supply the offset. The team demonstrated the hang on Postgres 13 and current branches, confirmed that SIGINT cannot break it, evaluated three unsafe fixes, then implemented a localized WAL-redo fix that pre-populates the next offset on the same SLRU page.

[timecodes · 8]
  1. Follow-up fixes for pg_dump policy comments
  2. MultiXacts and the standby deadlock report
  3. How MultiXact offsets and members are stored
  4. Circular wait between a reader and startup process
  5. Building a deterministic reproduction
  6. Debugging both sides of the deadlock
  7. Why three obvious fixes are unsafe
  8. Localized WAL-redo fix and successful test
#MultiXact@Nikolay Samokhvalov@Andrey Borodin@Kirk Wolak
-hackersCF #6070
committed

direct mapping
· 80:32 · youtube ↗

Vibe Hacking Postgres

Generic workshop near the start of the MultiXact standby-deadlock thread.

Responding to audience interest in locking, the group investigated a Postgres 17 standby hang introduced when a one-millisecond MultiXact polling sleep was replaced with condition variables. A reported workload could drive replica TPS to zero. They reconstructed the locking protocol, used AI to inspect the patch and report, and realized the likely failure is a true deadlock: a query waits for MultiXact replay while holding the heap page needed by startup. They planned timeout instrumentation and stronger diagnostics.

[timecodes · 8]
  1. Audience chooses locking as the topic
  2. MultiXact basics and foreign-key locking
  3. SLRU storage and the old polling sleep
  4. Condition-variable optimization in Postgres 17
  5. Replica TPS drops to zero in the reported workload
  6. Why standby replay changes the concurrency model
  7. Timeout workaround versus a real fix
  8. Identifying the heap-page deadlock
#MultiXact@Nikolay Samokhvalov@Andrey Borodin@Kirk Wolak
-hackers
committed

correlated mapping