hacking.postgres.tv
./menu

postgres=# select * from projects where slug = 'log-object-drops';

Recovery landmarks for destructive DDL

Log the correct commit-record LSN for DROP TABLE and related destructive operations to make PITR recovery less guessy.

active[PR #55 ↗][CF #6272 ↗][session notes ↗]

current state

active

blocker: The corrected PR changes have not yet been posted back to -hackers and CommitFest.

next

  • Finish review tracker
  • Send a new patch version to -hackers
  • Update the CommitFest entry

sessions

7
· 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
· 87:51 · youtube ↗

How to create Postgres patches with AI?

AI-assisted patch discovery, implementation, review, and submission.

The session developed a responsible AI-assisted patch workflow: treat prompts as engineering specifications, assign independent security, documentation, and testing reviewers, distrust praise, and use agents to summarize long CommitFest threads without surrendering judgment. They then applied that workflow to a patch that logs the LSN of DROP TABLE, enabling precise PITR after accidental deletion. The agent retrieved and rebased the patch, planned transaction, rollback, savepoint, and documentation tests, and continued adapting it to changed GUC infrastructure; final review remained pending.

[timecodes · 8]
  1. What AI changes in Postgres hacking
  2. Specifications and independent reviewer roles
  3. Maintenance work and critical AI feedback
  4. AI-assisted patch and CommitFest review
  5. Advice for learning Postgres development
  6. GSoC as an entry into core hacking
  7. Starting a live DROP TABLE logging review
  8. PITR use case, tests, and patch rebase
#AI-assisted hacking#hacking process@Nikolay Samokhvalov
tools PR #10
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
· 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