· 50:53 · youtube ↗
Back to “log LSN on DROP TABLE”
Fix correctness and coverage of recovery landmarks for destructive DDL.
Transcript summary and timecodes pending captions.
active
direct mapping
postgres@hacking:~$ ls people/andrey-borodin/sessions/
Andrey Borodin
PostgreSQL Major Contributor ↗Postgres hacker and recurring session participant. 32 sessions in the public archive.
direct mapping
· 77:12 · youtube ↗
Agent hacking Postgres
Agent-assisted patch work around the wait-event timing submission.
The group reviewed Kirk Wolak's pg_dump patch for keeping loadable placeholders when table data is excluded, grounding the discussion in his large-table restore workflow. They debated a positive interface, filter-file actions, arbitrary dump queries, PII transformation, and referential-integrity risks, then posted supportive review feedback to pgsql-hackers. The final segment examined Salma El-Sayed's B-tree leaf-page merge design, including merged-page markers, scan correctness, vacuum cleanup, and review plans.
[timecodes · 8]
- Postgres 19 development opens and patches await review
- Kirk introduces the pg_dump placeholder patch
- Large-table dump and one-command restore use case
- Reviewing the option name and user interface
- Using AI to review design and mailing-list history
- Parallel chunks for restoring one large table
- Custom dump queries, filtering, and PII transformation
- B-tree leaf-page merge design and scan safety
active
correlated 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]
- Returning to logical decoding on WAL-shipping standbys
- Recovering useful changes from a broken pull request
- Reviewing pause and auto-resume patches
- Conflict horizons and synchronized-slot behavior
- Dirty slot state and restart-point persistence
- Live transcript-assisted code investigation
- Restructuring the work into reviewable patches
- Crash-safety invariant and correctness-first decision
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]
- Archive-fed decoding for resilient analytics
- From meeting transcript to AI-built prototype
- Logical archive during large initial synchronization
- Pause replay instead of blocking primary vacuum
- Opening the prototype for manual review
- Understanding the pause-on-conflict TAP test
- Missing assertions for the paused recovery state
- Designing automatic recovery resume
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]
- Why decode archived WAL away from production
- Using an archive-fed standby as the decoder
- Standalone WAL tool versus a full Postgres server
- Slot conflicts and the need to pause replay
- Choosing a recovery mode driven by consumption
- Function-based recovery targets
- Stepping through WAL for correctness testing
- Filtered, PII-free staging from archived WAL
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]
- Command-tag customization and performance feedback
- Ideas for an extensible client/server protocol
- Language-server completion for psql
- Parallelizing logical-replication initialization
- Keeping an independent copy outside managed Postgres
- Turning archived WAL into a logical stream
- Designing a standalone offline decoder
- Checkpoints, full-page images, and pg_repack caveats
exploration
direct mapping
· 94:41 · youtube ↗
Command-tag customization
Custom protocol command tags and _pq_ capability negotiation.
After testing the newly committed REPACK command and confirming that it is transactional but takes an access-exclusive lock, the group built a prototype for customizable command-completion tags such as schema-qualified table names. A first server-only change broke psql's parser, exposing the need for client/server capability negotiation. The agent then used the existing _pq_ protocol-options framework so only requesting clients receive the new format. They reviewed compatibility tests and concluded the patch was useful for discussion but needed cleanup before pgsql-hackers.
[timecodes · 8]
- Testing the new REPACK command
- REPACK locking and transaction behavior
- Designing descriptive command tags
- Prototype-first agentic implementation
- Server-only format change breaks psql
- Why protocol feature negotiation is required
- Using the _pq_ protocol-options framework
- Compatibility review and patch cleanup
active
direct mapping
· 72:37 · youtube ↗
AI or not AI; GSoC 2026; improving pglz compression
Evaluate agentic hacking, develop GSoC project ideas, and experiment with pglz compression.
The first half examined AI-assisted Postgres development: community overload, specification-first agent workflows, independent review, and personal responsibility for generated work. The second half audited an agent-produced pglz optimization series. Existing benchmarks mixed runtime and work done, while some optimizations changed compressed output. The group therefore narrowed the project to byte-compatible changes, required old-versus-new output tests, fixed-transaction-count and multi-platform benchmarks, and a small reproducible pgsql-hackers result; a reported 14% workload gain still needed verification.
[timecodes · 8]
- AI risks for the Postgres community
- Specification-first autonomous agent workflows
- Quality, review, and ownership of AI output
- AI policy for Google Summer of Code
- Reviewing the pglz optimization project
- Why the benchmark methodology was misleading
- Compression correctness and corruption tests
- Byte-compatible scope and revised benchmark plan
exploration
direct mapping
· 69:49 · youtube ↗
GSoC ideas for Postgres
Turn workshop ideas into scoped GSoC projects, including wait-event coverage, pg_stat_statements scalability, and B-tree page merge.
The group turned Postgres GSoC brainstorming into a draft set of core-development projects. After Nikolay recounted his 2006 SQL/XML GSoC experience, they evaluated planner, parallel GiST build, TOAST slicing, test coverage, logged/unlogged tables, global temporary tables, and autovacuum ideas. They then added wait-event coverage, pg_stat_statements scalability, and B-tree page merge, using an AI-generated wiki draft. The draft still needed expert validation, clearer mentor ownership, and manual editing before merging into the official ideas page.
[timecodes · 8]
- Nikolay's 2006 SQL/XML GSoC project
- Reviewing existing core project ideas
- How GSoC ideas, mentors, and proposals match
- Logged tables and other deceptively hard projects
- Global temporary tables and autonomous work
- Autovacuum control and scheduling ideas
- Generating the GSoC wiki draft
- Wait events, page merge, and observability projects
exploration
direct mapping
· 73:44 · youtube ↗
Vibe Hacking Postgres
Prototype merging sparse B-tree leaf pages and audit its correctness failures.
The workshop focused on a prototype for reclaiming B-tree bloat by merging adjacent sparse leaf pages. Kirk proposed an incremental, access-exclusive-lock design that first merges only one pair, prioritizing correctness of forward and backward scans. The pgindex_reclaim extension identified merge candidates, but execution crashed. Inspection showed incomplete parent-page handling and incorrect WAL/critical-section logic. The group chose to stop trusting the generated merge code, add a reproducible regression test, study related upstream page-deletion work, and restart from the smallest verifiable merge.
[timecodes · 8]
exploration
direct mapping
· 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]
- AI-assisted audit of missing wait events
- Review discipline and excluding CPU work
- Choosing COPY FROM PROGRAM as the first target
- Reproducing the unreported external-program wait
- Prototyping COPY program wait events
- Testing COPY TO PROGRAM and separating code paths
- Discovering ordinary COPY file I/O gaps
- Validating coverage with pg_wait_sampling
committed
direct mapping
· 88:38 · youtube ↗
WHERE support for REFRESH MATERIALIZED VIEW
Partial refresh restricted by a predicate, including concurrency semantics.
The session explored adding a WHERE clause to REFRESH MATERIALIZED VIEW so selected rows can be refreshed without rebuilding the whole result. Reading the concurrent-refresh implementation revealed that Postgres creates a temporary difference table, then applies ordinary SQL deletes and inserts through SPI. After experimentally bypassing the normal DML guard, updates to a materialized view and its indexes worked. The group concluded that partial refresh looked technically approachable, while delete semantics, grammar, safety, and consistency still needed design work.
[timecodes · 7]
- The case for partial materialized-view refresh
- Building a concurrent-refresh test case
- Tracing REFRESH through parser and executor code
- How concurrent refresh computes and applies a diff
- Designing a filtered merge without global deletes
- Testing direct DML on a materialized view
- Conclusions and remaining partial-refresh semantics
active
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]
- Postgres 18 outcomes: UUIDv7 and GIN checks
- Responsible AI-assisted Postgres hacking
- Why the B-tree merge prototype was paused
- Revisiting a recovery landmark for DROP TABLE
- Prompting a callback and extension prototype
- Building and loading the DROP TABLE extension
- Combining object-access and commit callbacks
- Recovery-event catalogs and the invalid-LSN blocker
exploration
direct mapping
· 51:42 · youtube ↗
Vibe Hacking Postgres
Test B-tree page merge against concurrent scans and expose correctness failures.
The group assessed the B-tree page-merge prototype after community feedback. They agreed benchmarks should emphasize extra buffer I/O, cache pollution, WAL, and sparse-page workloads rather than lookup latency alone. A new injection-point test then demonstrated the critical flaw: a concurrent forward scan returned duplicates while a backward scan missed tuples after pages were merged. Several recovery schemes were examined, but repeated vacuums and concurrent inserts defeated the simple designs. The session ended with correctness and concurrency still unresolved.
[timecodes · 8]
- Community feedback and the benchmark requirement
- Why sparse pages hurt buffers, WAL, and vacuum
- Scoping useful page-merge benchmarks
- Injection-point test exposes incorrect scans
- Visualizing the old-tree and new-tree race
- Concurrent inserts and possible query aborts
- When scans can recover from merged pages
- Why limited merges and repeated vacuums still fail
exploration
direct mapping
· 97:08 · youtube ↗
Index bloat and B-tree page merge, part 3
Continue page-merge implementation and correctness work.
The group refined a minimal B-tree merge: move tuples from a very sparse leaf page into its right sibling, then reuse existing page-deletion machinery. They inspected page layouts, asked an agent to implement the change inside vacuum, and built a sparse index. After removing an assertion, one page was successfully emptied without a crash. However, regression and foreign-key tests failed, and concurrent scans were not tested, so the result remained a potentially corrupt prototype rather than a valid patch.
[timecodes · 8]
- Recap: turning sparse leaf pages into deletable pages
- Comparing candidate leaf-page merge layouts
- Applying Lehman-Yao page-merge ideas to Postgres
- Minimal plan: move tuples, then reuse page deletion
- Inspecting leaf pages before and after vacuum
- Prompting the first vacuum-integrated implementation
- Building a sparse-index test for the prototype
- One merge succeeds, but regression tests fail
active
correlated mapping
· 75:39 · youtube ↗
Index bloat and B-tree page merge, part 2
Continue B-tree page-merge design and prototype.
The session established why sparse B-tree pages matter: they increase buffer churn, WAL full-page images, replica storage, and the cost of scans. The group then traced vacuum's existing half-dead page deletion and studied whether a merge could resemble a split. Moving tuples directly exposed a duplicate-read race for concurrent scans, implying a two-phase protocol that removes the parent downlink before relocation. By the end they identified split/finish-split as the code to reverse, but deferred implementation pending a sound scan protocol.
[timecodes · 8]
- Operational costs of sparse B-tree pages
- Why Postgres has reindexing but no page merge
- Can merge be shaped like an existing page split?
- Tracing vacuum and half-dead page deletion
- Moving tuples into a sibling before deletion
- Concurrent scans expose duplicate reads
- A two-phase merge and scan-awareness requirement
- Reversing finish-split becomes the next design step
exploration
correlated mapping
· 84:02 · youtube ↗
Index bloat and B-tree page merge, part 1
Merge sparse sibling B-tree pages to reduce bloat.
This B-tree page-merge session moved from automated REINDEX toward fixing the cause of persistent bloat. The group defined the target as partially empty leaf pages that vacuum cannot reclaim, then had an agent build a logical leaf-page scan that reports adjacent pages fitting into one block. On a randomized 90%-deleted workload it found widespread merge opportunities. They did not implement merging: backward-scan visibility, transaction horizons, WAL replay, lock coupling, and undetectable lightweight-lock deadlocks were identified as the core design problems.
[timecodes · 8]
- From automated REINDEX to B-tree page merge
- Defining the persistent bloat worth fixing
- Planning a logical scan for merge candidates
- Agent-assisted prototype of the merge checker
- Correcting physical scan to logical leaf order
- The logical adjacency scanner works
- Randomized deletion reveals widespread candidates
- Backward scans, WAL, and lock-coupling hazards
exploration
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]
- Follow-up fixes for pg_dump policy comments
- MultiXacts and the standby deadlock report
- How MultiXact offsets and members are stored
- Circular wait between a reader and startup process
- Building a deterministic reproduction
- Debugging both sides of the deadlock
- Why three obvious fixes are unsafe
- Localized WAL-redo fix and successful test
committed
direct mapping
· 81:56 · youtube ↗
Vibe Hacking with Dmitry Fomin
Wait-event observability and precise tracing ideas.
Dmitry Fomin presented his first core patch after tracing synchronous-replication latency spikes to blocking fdatasync calls in the standby WAL receiver, even under synchronous_commit=remote_write. His prototype batches flushes by byte threshold or timeout. Review uncovered unsafe defaults for stronger synchronous modes and suggested a separate flusher process as a cleaner long-term design. They rebased the old patch onto master, removed redundant unflushed-byte state, compiled it, and prepared it for pgsql-hackers discussion.
[timecodes · 8]
- Production SyncRep latency problem
- fdatasync stalls in remote_write mode
- Batching WAL flushes by bytes or timeout
- What synchronous replication actually guarantees
- Reviewing the new WAL-receiver settings
- Defaults break stronger synchronous-commit modes
- Alternative design with a separate WAL flusher
- Rebasing, reviewing, and preparing the patch
active
correlated 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]
- Audience chooses locking as the topic
- MultiXact basics and foreign-key locking
- SLRU storage and the old polling sleep
- Condition-variable optimization in Postgres 17
- Replica TPS drops to zero in the reported workload
- Why standby replay changes the concurrency model
- Timeout workaround versus a real fix
- Identifying the heap-page deadlock
committed
correlated mapping
· 87:17 · youtube ↗
Vibe Hacking Postgres
Rebase GiST amcheck and design useful corruption tests.
The group revived the long-running amcheck work for GiST indexes after shared infrastructure and the GIN checker had been committed. They manually rebased the remaining GiST patch, repaired build files and SQL upgrade scripts, and got its basic checks passing. They then asked Cursor to adapt newly committed GIN corruption tests. The generated tests initially assumed ordering that GiST does not have and later passed without actually corrupting indexes, leaving only a useful page-header corruption idea and more manual work.
[timecodes · 8]
- Reviving unfinished GiST amcheck work
- Applying the old patch to current Postgres
- Cursor overreaches while resolving rejects
- Manual rebase of build and extension files
- Compiling and running the basic GiST checks
- Recent GIN corruption tests as a template
- Reviewing AI's GiST corruption-test design
- Tests pass, but no corruption was injected
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]
- Reality-checking AI-generated implementations
- Goal: log an LSN before destructive DDL
- Reviewing three patch iterations
- Why raw LSNs break regression-test output
- Finding unused schema-drop code
- Manual testing exposes missing schema logging
- Deferring patch cleanup and changing tasks
- Cursor rebalances the regression-test schedule
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]
- Opening review of the pg_resetwal patch
- What pg_resetwal changes and why it is dangerous
- DBLab recovery needs a different system identifier
- Mailing-list feedback on safeguards and docs
- AI-assisted Postgres patch workflow
- Indexing the tree and structuring small changes
- Strict review with a stronger model
- Human review finds option and parsing issues
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]
- An AI-written pg_dump change reaches Postgres 18
- The hallucination that inspired wal_compression levels
- Tests and documentation in agentic development
- Returning to destructive-DDL LSN logging
- Comparing the original patch with Jim's version
- First Cursor attempt overreaches
- Supplying both patches for a focused merge
- Manual test exposes callback leakage
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]
- GIN amcheck and corruption detection
- Recent read-stream and statistics work
- Revisiting DROP TABLE recovery logging
- Why attempted-drop logging is ambiguous
- Testing an AI coding agent on Postgres
- Passing the commit LSN to transaction callbacks
- Implementing the core changes manually
- Working result and remaining patch tasks
active
direct mapping
· 48:43 · youtube ↗
Include ANALYZE steps in all dumps, part 2
Continue design and patch work on dump-time analysis.
Part two implemented the pg_dump side of per-object ANALYZE. The group modeled ANALYZE as a new dumpable archive object, dependent on its table and emitted in the post-data section after data and indexes. They limited the first prototype to ordinary tables and materialized views, excluding sequences, views, and foreign tables. The code compiled, but no ANALYZE appeared in output because the new object was not reached or enabled correctly; print debugging exposed control-flow problems, and they deferred completion.
[timecodes · 8]
- Resuming from pg_dump archive entries
- Creating a dumpable ANALYZE object
- Tables, partitions, foreign tables, and sequences
- Object IDs and table dependencies
- Choosing an ArchiveEntry implementation
- Building the ANALYZE command in post-data
- Enabling ANALYZE and considering opt-out
- Compilation succeeds, output debugging begins
exploration
direct mapping
· 44:37 · youtube ↗
Include ANALYZE steps in all dumps, part 1
Preserve or trigger statistics collection in dump/restore output.
The group investigated why pg_restore leaves restored relations without planner statistics and agreed that a database-wide ANALYZE in pg_restore would be too coarse. Instead, pg_dump should add an ANALYZE entry for every dumped table so archive filtering and partial restores retain correct behavior. They explored directory-format archives, TOC dependencies, table-data files, materialized-view refresh ordering, and index ArchiveEntry code. They concluded ANALYZE belongs after data, indexes, and materialized-view population, then began defining a new DumpableObject type before the call ended.
[timecodes · 8]
- Why restored databases need ANALYZE
- Choosing pg_dump over a global pg_restore step
- Materialized views as the ordering model
- Exploring directory archives and the TOC
- How table definitions and data entries connect
- ANALYZE must follow indexes and refreshes
- Adding a new DumpableObject priority
- Learning from index ArchiveEntry generation
exploration
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]
- Two recovery and restore ideas
- Choosing the DROP TABLE recovery problem
- Considering an automatic restore-point record
- Which dropped objects need protection
- Tracing DROP through parser and dependency code
- Intent, permissions, locks, and rollback
- Why no usable LSN exists before WAL
- Final log message and mailing-list patch
active
direct mapping
· 86:12 · youtube ↗
URLs in psql \h output
Link psql help to online SQL-command documentation.
The group prototyped richer psql help after noting that autocomplete and backslash-h do little for functions or unknown keywords. They modified the no-match path to print clickable documentation or search URLs, added a configurable HELP_URLS variable containing pipe-separated templates, implemented substitution and URL encoding, and tested PostgreSQL.org, Google, and DuckDuckGo links. They kept PostgreSQL.org as the default, refined the wording, and prepared a discussion patch while leaving external API/LLM help and reusable URL functions as future ideas.
[timecodes · 8]
exploration
correlated 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]
- UUIDv7 status and the evolving RFC
- Monotonic counters and distributed generators
- Why UUIDv7 combines ordering and randomness
- Timestamp extraction and partitioning
- SLRU locking and subtransaction edge cases
- Transaction timeout lands, tests remain flaky
- Replacing fixed sleeps with injection points
- False success, broken pipes, and unfinished cleanup
exploration
direct mapping
· 50:41 · youtube ↗
Configurable command tag, part 1
Explore custom command-completion tags returned to clients.
The session attempted to make PostgreSQL command-completion tags configurable, motivated by dump and restore output that says INSERT or COPY without identifying the relation. The proposed GUC would format tags with placeholders such as command name and relation names while preserving protocol compatibility. They threaded relation information through executor structures and reused a placeholder formatter, but the server repeatedly crashed because the helper was called incorrectly. The prototype remained unfinished, with lazy calculation of optional fields also identified as necessary.
[timecodes · 8]
- Updates on earlier patches and reviews
- Why command tags need relation context
- A configurable placeholder-based tag format
- Threading relation names through query completion
- Adding the command_tag_format GUC
- Formatting command and relation placeholders
- Server crashes and binary-search debugging
- Incorrect helper usage and unfinished prototype
active
correlated mapping
· 44:28 · youtube ↗
Postgres Hacking 101 with Andrey
Follow-up workshop likely reviewing the bounded psql \watch work.
After explaining CommitFest and release-cycle mechanics, the group designed extensible command-completion tags instead of changing PostgreSQL's long-stable protocol output directly. A format string could optionally include timestamps and affected relations, especially for readable dump and restore progress. They postponed implementation, then reviewed a libpq patch that randomizes a multi-host connection list. The Fisher-Yates shuffle appeared correct despite confusing code and minor whitespace issues, but they noted that randomization alone cannot avoid a slow replica and suggested future latency-aware selection.
[timecodes · 8]
- CommitFest cadence and the PostgreSQL release cycle
- What command-completion tags currently report
- Relation names and compatibility constraints
- Designing a configurable command-tag format
- Reviewing libpq multi-host load balancing
- Random ordering cannot avoid a slow replica
- Refactoring addresses out of PGconn
- Checking the Fisher-Yates shuffle implementation
committed
correlated mapping