April 8 marked the start of feature freeze for PostgreSQL 19. For anyone unfamiliar with the PostgreSQL development cycle, that means that as of April 8 no new features are accepted for the upcoming major version. From April until the final release in the second part of the year, the community works on beta releases, bug fixes, and documentation. If a major feature isn't ready by the April deadline, it cannot be "snuck in." Conversely, stuff that is committed before the feature freeze isn't automatically making it into the new version as is. Patches might still get reversed, or stripped down. 

April 15 Bruce Momjian published the draft release notes for 19, when the feature count was at 212. At the time of the freeze, we committed 32 EDB-authored patches to PostgreSQL 19. 

I asked several PostgreSQL hackers at EDB about what features and fixes they're excited about. 

Shiny stuff 

Peter Eisentraut has put a bunch of work into PGQ, which is going to open PostgreSQL as a database for graph database workloads. “It's a different way of interacting with data (a paradigm shift if you will), like document database/JSON, or object-relational.” A hacker with his track record, we’re pretty sure users will be enjoying this functionality very soon. 

Robert Haas’ big thing this year is pg_plan_advice, which for a moment looked like it was going to get rolled over into v20 but is committed now. He wrote a blog post about the functionality it introduces (which he feels like needs a part 2 to reflect the updated state of things). The short version: you can use pg_plan_advice for plan stability, or to override the planner’s judgement. You do this either by setting pg_plan_advice.advice to a suitable advice string just before the query is planned and clearing it just after, or else you use pg_stash_advice to automatically supply an advice string every time a certain query ID is seen. You figure out the advice string by using EXPLAIN (PLAN_ADVICE) as a starting point, and then cutting it down or modifying it as you wish. 

Álvaro Herrera, with Mihail Nikalayeu, and led by Antonin Houska (Cybertec) will see their work on REPACK CONCURRENTLY go into the next release. Alvaro and Antonin already teased this functionality at last year’s PGConf EU, in Riga. The pitch? REPACK goes further where VACUUM FULL falls short, and gets rid of table bloat without locking tables. 

Richard Guo committed eager aggregation for plan optimization. The patch title mentions “take 3”, since earlier attempts by other hackers in 2017 and then 2022 never made the cut. The third time proved the charm, the work was committed. 

Andrew Dunstan shared this about a set of patches by Amul Sul that he ultimately committed, making pg_waldump work on tar files: “Prior to these changes, pg_verifybackup could not deal with tar format backups. Now, via Amul’s work on getting this feature enabled in pg_waldump, it can.” A real troubleshooting enhancement, saving time and space. 

Euler Taveira with his fine-grained log_min_messages patch introduced the ability to do highly targeted debugging. “It allows you to increase the verbosity in a specific auxiliary process without altering the configuration that affects all Postgres processes.” Increased log verbosity on a busy production server can lead to running out of disk space, severe IO performance degradation, and it’s like looking for the so-called needle in the haystack. Isolating the high-verbosity logs to a single auxiliary process makes it so that DBAs can do their troubleshooting in production, without impacting the current workload. 

PostgreSQL 19 will see the first pieces of a project aimed to provide SQL functions that emit the Data Definition Language (DDL) for any database object. Up to now, the only way to get that DDL has been to run pg_dump on the database and pg_dumpall on the cluster for global objects. The first round of these cover global object types: databases, roles and tablespaces. These patches have been contributed by participants in EDB Developer U program: Akshay Joshi, Nishant Sharma, Manni Wood, Mario Gonzalez, and Bryan Green. The group is set on covering the remaining database object types for release 20. 

EDB Jacob Champion comments on a few notable patches submitted by others: 

• Asynchio was introduced in PG 18, in 19 we’ll see increased performance. 
• GROUP BY ALL by David Christensen (Snowflake) simplifies queries, reducing the need to spell out everything. 
• Masahiko Sawada (AWS) submitted a change that enables logical decoding without restarting the server - just one of those papercuts that is just annoying, and now it’s … no longer necessary! 

It can’t always be shiny stuff though 

Jacob says that he feels he didn’t really do anything aside from “firming up the damage I did last year”. You might remember the introduction of support for the OAuth that took 4 years to make it into Core. Certainly not an outlier in terms of time it may take to get a patch committed, but nevertheless a timeline that can be hard to explain to your colleagues working on commercial products, with sprints and more frequent release cycles. In fact, online checksums, also slated for 19, is a pre-pandemic patch! 

“OAuth was so large, it was impossible to get everything in, the first time around. Refining that was plenty of work!” REPACK definitely is Alvaro’s “OAuth” this year around. “Releasing that will enable a bunch of stuff that will become apparent in PG 20.” 

Peter is actually looking forward to spending the next cycle on maintenance. It may not be glamorous, but it’s extremely important to invest in the stability of the project. 

What’s next? 

PostgreSQL 19 GA is expected in September/October, just in time for the community to get together at the largest PostgreSQL conference in the world: PGConf.EU. Taking place in Valencia, Spain, the program is yet to be published but like every year feature previews and walk-through are very certainly part of the schedule. As the release date creeps closer we’ll publish more deep-dives from our hackers, and we’ll see you in Valencia!