hacking.postgres.tv
./menu

postgres=# select * from sessions where topic = 'recovery';

#recovery

13 related sessions.

· 50:53 · youtube ↗

Back to “log LSN on DROP TABLE”

Fix correctness and coverage of recovery landmarks for destructive DDL.

The group returned to commit-LSN logging for DROP TABLE and related destructive DDL, using several AI agents to review and repair the revived patch. They rejected an extension split, found that the hook exposed the end rather than the start of the commit record, and revised the code to log the precise recovery boundary without a concurrency race. After considering restore points and event triggers as alternatives, they audited documentation and an end-to-end restore test, then prepared a PostgreSQL-style commit message, a new pgsql-hackers revision, and CI for the fork.

[timecodes · 10]
  1. Reviving commit-LSN logging for destructive DDL
  2. Asking AI for a broader architectural review
  3. Concrete bugs, missing tests, and CommitFest plans
  4. Core feature versus extension design
  5. B-tree page-merge and wait-coverage updates
  6. Finding the wrong commit-record LSN boundary
  7. Reviewing the repaired patch and documentation
  8. Restore points and event triggers as alternatives
  9. End-to-end recovery test and patch readiness
  10. Commit message, pgsql-hackers email, and CI
#recovery@Nikolay Samokhvalov@Andrey Borodin@Kirk Wolak
PR #55issue #53issue #54review #56summary #57-hackersCF #6272
active

direct mapping
· 78:11 · youtube ↗

Agentic Hacking Postgres

End-to-end tests for archive-fed logical decoding and pause/resume behavior.

The session refined logical decoding from an archive-fed physical standby as a recoverable, production-independent pipeline: after losing the decoding node, a consumer can restore another standby at the acknowledged LSN and tolerate overlap. They reviewed the three-patch implementation and TAP test, found registration and naming issues, debated lock structure, and judged the code ready for discussion after fixes. They then specified an end-to-end WAL-G test with catalog churn, paused consumption, catch-up, and a final marker.

[timecodes · 8]
  1. Recoverable decoding after a standby is lost
  2. Archive-fed WAL decoding without touching production
  3. Naming the feature: logical decoding from archive
  4. Reviewing the three-patch implementation
  5. TAP test registration and test readability
  6. Reviewing pause-on-conflict code and locking
  7. Patch readiness and concrete submission fixes
  8. Designing an end-to-end WAL-G recovery test
#logical decoding#recovery#WAL#AI-assisted hacking@Nikolay Samokhvalov@Kirk Wolak
test design #43
active

direct mapping
· 53:58 · youtube ↗

Logical replication from physical standbys on WAL shipping

Refine recovery pause behavior, crash safety, promotion, and auto-resume.

The group inspected two AI-produced patch branches for pausing archive recovery when replay would invalidate a logical slot. They reconstructed the patch series, reviewed synchronized-slot and promotion behavior, and clarified that dirty slot state is only persisted at restart points, weakening crash guarantees. The concrete conclusion was to favor correctness, consolidate the work into one reviewable three-patch series, preserve readable code over premature lock optimization, and target the July CommitFest after further testing.

[timecodes · 8]
  1. Returning to logical decoding on WAL-shipping standbys
  2. Recovering useful changes from a broken pull request
  3. Reviewing pause and auto-resume patches
  4. Conflict horizons and synchronized-slot behavior
  5. Dirty slot state and restart-point persistence
  6. Live transcript-assisted code investigation
  7. Restructuring the work into reviewable patches
  8. Crash-safety invariant and correctness-first decision
#logical decoding#recovery#WAL@Nikolay Samokhvalov@Andrey Borodin
PR #40
active

direct mapping
· 93:07 · youtube ↗

Hacking Postgres with Andrey, Kirk, Nik

Pause replay instead of invalidating conflicting logical slots; design auto-resume.

The group connected archive-fed logical decoding to resilient analytical replication: replay should pause before catalog cleanup invalidates a lagging slot, then resume automatically once consumption catches up. They manually audited an AI-generated prototype and its complex TAP test, discovering that the test needed clearer assertions around the actual paused state. They accepted a proof-of-concept pause GUC, rejected manual resume as incomplete, and designed auto-resume behavior for drained, dropped, or otherwise nonblocking slots.

[timecodes · 8]
  1. Archive-fed decoding for resilient analytics
  2. From meeting transcript to AI-built prototype
  3. Logical archive during large initial synchronization
  4. Pause replay instead of blocking primary vacuum
  5. Opening the prototype for manual review
  6. Understanding the pause-on-conflict TAP test
  7. Missing assertions for the paused recovery state
  8. Designing automatic recovery resume
#logical decoding#recovery@Nikolay Samokhvalov@Andrey Borodin@Kirk Wolak
PR #27PR #30
active

direct mapping
· 39:42 · youtube ↗

Logical decoding of archived WALs

Use an archive-fed standby as a logical-decoding engine.

The session began by testing whether Postgres 16's logical decoding on a standby could turn an archive-fed recovery instance into a detached decoding engine. The group concluded a full server is the practical first implementation because it supplies catalog snapshots and output plugins; the missing behavior is to pause replay when it would invalidate a slot and continue when consumption advances. They also identified broader uses: per-record WAL verification, recovery debugging, and filtered, PII-free staging streams.

[timecodes · 8]
  1. Why decode archived WAL away from production
  2. Using an archive-fed standby as the decoder
  3. Standalone WAL tool versus a full Postgres server
  4. Slot conflicts and the need to pause replay
  5. Choosing a recovery mode driven by consumption
  6. Function-based recovery targets
  7. Stepping through WAL for correctness testing
  8. Filtered, PII-free staging from archived WAL
#logical decoding#recovery#WAL@Nikolay Samokhvalov@Andrey Borodin@Kirk Wolak
blueprint PR #24Sprint 0 #25PR #27
active

direct mapping
· 55:36 · youtube ↗

Hacking Postgres with Kirk, Andrey, Nik

Custom command tags and logical decoding from an archive-fed recovery server.

The workshop first revisited customizable command tags, confirming legacy behavior remains the default and its added branch should be negligible, then explored extensible client protocols and better psql completion. The main direction was extracting data from managed Postgres without burdening production: decode archived WAL into a logical stream. They compared a full recovery server with a standalone tool, concluding the latter would need schema state at a starting LSN, checkpoint/full-page-image handling, and careful treatment of file swaps such as pg_repack.

[timecodes · 8]
  1. Command-tag customization and performance feedback
  2. Ideas for an extensible client/server protocol
  3. Language-server completion for psql
  4. Parallelizing logical-replication initialization
  5. Keeping an independent copy outside managed Postgres
  6. Turning archived WAL into a logical stream
  7. Designing a standalone offline decoder
  8. Checkpoints, full-page images, and pg_repack caveats
#logical decoding#recovery#WAL#hacking process@Nikolay Samokhvalov@Andrey Borodin@Kirk Wolak
no public artifact mapped
exploration

direct mapping
· 70:24 · youtube ↗

Vibe Hacking Postgres

Review B-tree merge blockers and prototype commit-LSN logging for DROP TABLE.

After reviewing UUIDv7 and amcheck support for GIN in Postgres 18, the group discussed responsible AI-assisted hacking and briefly parked the B-tree merge work over unresolved scan concurrency. Most of the session revisited recovery from accidental DROP TABLE: they asked an agent to extend transaction callbacks with the commit LSN and build a logging extension. The prototype found table names through object-access hooks, but cleanup timing and an invalid commit LSN prevented a working result, leaving the design unfinished.

[timecodes · 8]
  1. Postgres 18 outcomes: UUIDv7 and GIN checks
  2. Responsible AI-assisted Postgres hacking
  3. Why the B-tree merge prototype was paused
  4. Revisiting a recovery landmark for DROP TABLE
  5. Prompting a callback and extension prototype
  6. Building and loading the DROP TABLE extension
  7. Combining object-access and commit callbacks
  8. Recovery-event catalogs and the invalid-LSN blocker
#recovery#B-tree#hacking process@Nikolay Samokhvalov@Andrey Borodin@Kirk Wolak
no public artifact mapped
exploration

direct mapping
· 73:25 · youtube ↗

Vibe Hacking Postgres

Review commit-LSN logging for destructive DDL and its test strategy.

The workshop resumed the patch that logs a recovery LSN when destructive DDL commits. Review showed AI-generated schema support used the wrong hook, added an uncalled function, and supplied a nondeterministic regression test unsuitable for raw LSN output; a TAP test was deemed necessary. Rather than finish the substantial cleanup live, they switched to optimizing the regression-test schedule with Cursor. Its reordered groups caused failures and thermal throttling, demonstrating that faster scheduling must respect test dependencies and stable benchmarking conditions.

[timecodes · 8]
  1. Reality-checking AI-generated implementations
  2. Goal: log an LSN before destructive DDL
  3. Reviewing three patch iterations
  4. Why raw LSNs break regression-test output
  5. Finding unused schema-drop code
  6. Manual testing exposes missing schema logging
  7. Deferring patch cleanup and changing tasks
  8. Cursor rebalances the regression-test schedule
#recovery#hacking process@Nikolay Samokhvalov@Andrey Borodin@Kirk Wolak
no public artifact mapped
active

direct mapping
· 80:57 · youtube ↗

Vibe Hacking Postgres

Add a pg_resetwal system-identifier option and audit the agentic patch workflow.

Nik presented an AI-assisted pg_resetwal option for changing the system identifier, needed to replay archived WAL after DBLab created a replacement cluster. Review accepted the use case but called for removing interactive safeguards, shortening documentation, reducing redundant tests, and aligning option identifiers with other frontend tools. The session then demonstrated Nik's agentic patch workflow: small commits, specification-first documentation, compilation and manual tests, strict review by stronger models, and a final human review that caught issues the models missed.

[timecodes · 8]
  1. Opening review of the pg_resetwal patch
  2. What pg_resetwal changes and why it is dangerous
  3. DBLab recovery needs a different system identifier
  4. Mailing-list feedback on safeguards and docs
  5. AI-assisted Postgres patch workflow
  6. Indexing the tree and structuring small changes
  7. Strict review with a stronger model
  8. Human review finds option and parsing issues
#recovery#hacking process@Nikolay Samokhvalov@Andrey Borodin@Kirk Wolak
no public artifact mapped
exploration

direct mapping
· 74:57 · youtube ↗

Vibe Hacking Postgres

Merge improvements into commit-LSN logging for destructive DDL.

The session opened with AI-assisted Postgres development lessons from the committed pg_dump policy patch and a separate wal_compression-level prototype: write tests and documentation early, review every line, and use several strong models as independent critics. The practical task was merging Jim Jones's improvements into the patch that logs commit LSNs for destructive DDL. Cursor produced overbroad changes, but after resetting and supplying both patches, the group compiled and manually tested the result, found a callback-unregistration bug, and attempted test-driven repair.

[timecodes · 8]
  1. An AI-written pg_dump change reaches Postgres 18
  2. The hallucination that inspired wal_compression levels
  3. Tests and documentation in agentic development
  4. Returning to destructive-DDL LSN logging
  5. Comparing the original patch with Jim's version
  6. First Cursor attempt overreaches
  7. Supplying both patches for a focused merge
  8. Manual test exposes callback leakage
#recovery#hacking process@Nikolay Samokhvalov@Andrey Borodin@Kirk Wolak
no public artifact mapped
active

direct mapping
· 74:59 · youtube ↗

Hacking Postgres with Andrey and Nik

Redesign DROP TABLE recovery logging around the commit LSN.

The session opened with recent Postgres work on GIN amcheck, corruption detection, read streams, and pg_stat_statements sampling, then returned to the DROP TABLE recovery patch. The patch logged an attempted drop before commit, producing misleading landmarks after rollback. They redesigned transaction callbacks to receive the commit LSN, manually changed the commit path after an AI attempt stalled, and demonstrated commit-only logging. Remaining work included two-phase commit, schema/OID formatting, tests, and incorporating Jim Jones's review before a new version.

[timecodes · 8]
  1. GIN amcheck and corruption detection
  2. Recent read-stream and statistics work
  3. Revisiting DROP TABLE recovery logging
  4. Why attempted-drop logging is ambiguous
  5. Testing an AI coding agent on Postgres
  6. Passing the commit LSN to transaction callbacks
  7. Implementing the core changes manually
  8. Working result and remaining patch tasks
#recovery#hacking process@Nikolay Samokhvalov@Andrey Borodin
no public artifact mapped
active

direct mapping
· 108:13 · youtube ↗

Simplify recovering from a DROP TABLE

Log a recovery landmark when destructive DDL commits.

The group designed a recovery landmark for accidental DROP TABLE. They first considered emitting a named restore-point WAL record, then traced deletion through parser, dependency, permission, and lock paths. Rollback and the absence of a fresh LSN before any WAL write made that design misleading. They pivoted to logging a restore LSN after the table lock is acquired but before deletion, restricted it to ordinary tables, demonstrated the output, and prepared a small pgsql-hackers patch.

[timecodes · 8]
  1. Two recovery and restore ideas
  2. Choosing the DROP TABLE recovery problem
  3. Considering an automatic restore-point record
  4. Which dropped objects need protection
  5. Tracing DROP through parser and dependency code
  6. Intent, permissions, locks, and rollback
  7. Why no usable LSN exists before WAL
  8. Final log message and mailing-list patch
#recovery@Nikolay Samokhvalov@Andrey Borodin@Kirk Wolak
-hackersCF #5386CF #6272
active

direct mapping
· 93:53 · youtube ↗

Hacking Postgres — Andrey, Kirk, Nikolay

Review UUIDv7 and build deterministic transaction_timeout tests.

The first section reviewed UUIDv7's evolving RFC, monotonic counter, distributed generation, timestamp extraction, and blocked core support. They also surveyed transaction-timeout and SLRU-locking work. The hands-on section tackled flaky transaction-timeout tests by combining injection points with a background psql watch loop. Testing uncovered false success from malformed watch parameters and a broken-pipe cleanup problem when timeout killed psql. The harness remained unfinished, needing a reliable way to detect whether the background session is active.

[timecodes · 8]
  1. UUIDv7 status and the evolving RFC
  2. Monotonic counters and distributed generators
  3. Why UUIDv7 combines ordering and randomness
  4. Timestamp extraction and partitioning
  5. SLRU locking and subtransaction edge cases
  6. Transaction timeout lands, tests remain flaky
  7. Replacing fixed sleeps with injection points
  8. False success, broken pipes, and unfinished cleanup
#recovery#hacking process@Nikolay Samokhvalov@Andrey Borodin@Kirk Wolak
UUIDv7 committransaction_timeout commit
exploration

direct mapping