PGConf.EU 2026 – Day 2 & 3

Vacuum and autovacuum

I started the second day of PGConf.EU with a session about vacuum and autovacuum, presented by Teresa Lopes.
After a short introduction to how MVCC works, she presented the different elements related to autovacuum:
What are the different phases of autovacuum? What can trigger autovacuum? Which parameters can influence autovacuum? All these points were explained in a simple and clear way during the presentation.
Teresa also presented several reasons why autovacuum might not start, including a long-running transaction, an abandoned replication slot or an abandoned prepared transaction.

The second half of the presentation focused on new autovacuum features in PostgreSQL 19, for example:

• The scoring system for autovacuum, based on criteria such as XID/MXID age and the number of inserted, updated or deleted tuples.
• The possibility to use parallel workers for index vacuuming and cleanup.
• Improved ways to observe and monitor autovacuum, especially through new views and new logging parameters.

The session ended with a look at how to recover disk space in tables after autovacuum has cleaned them up, especially with REPACK, which also has a CONCURRENTLY option that allows other transactions to use the table while it is being repacked.

Zero downtime?

Speaking about REPACK, this new feature was also presented by Rajni Baliyan during her presentation about how to achieve zero downtime with PostgreSQL 19.
REPACK CONCURRENTLY allows tables to be reorganized and disk space to be recovered without blocking normal database operations for the entire process. Unlike VACUUM FULL, which blocks access to the table during the operation, REPACK CONCURRENTLY allows applications to continue reading and writing data while a new copy of the table and its indexes is being created.
In the background, PostgreSQL uses logical decoding to capture changes made to the original table during this process and applies them to the new copy. At the end, it briefly takes an exclusive lock to replace the old table and indexes with the new ones.

An other interesting feature is the new logical sequence synchronization worker, which helps keep sequence values synchronized between the publisher and the subscriber during logical replication.
Before PostgreSQL 19, sequence values were not automatically synchronized through logical replication. This could cause problems during major version upgrades, as sequences on the new server could have outdated values and generate duplicate IDs.
With PostgreSQL 19, sequences can now be synchronized automatically when a subscription is created. The REFRESH SEQUENCES command can also be used to synchronize them again when needed.

As you may have guess, the goal of this presentation was to show how new features can help reduce service interruptions during database maintenance and remove the need for maintenance windows. The presentation focused on making database operations easier and safer while keeping services available for users.
It was an interesting topic, especially for production environments where downtime must be avoided as much as possible.

Modern Backups for PostgreSQL

I then attended a session about pg_hardstorage, presented by Hans-Jürgen Schönig.
pg_hardstorage is a modern backup solution for PostgreSQL, designed especially for large environments and critical systems.
Unlike traditional backup tools, it uses the PostgreSQL replication protocol to retrieve a base backup and continuously stream WAL files. It does not require an agent or direct shell access on the database server. The tool runs on a separate backup host.

One interesting feature is its storage system. Each backup is treated as a full backup, but duplicate data blocks are stored only once. This reduces storage requirements without the complexity of traditional incremental backup chains.
The continuous WAL streaming also allows point-in-time recovery, making it possible to restore a database to a specific moment in time.

Another advantage is that pg_hardstorage can store backups on a filesystem or S3-compatible object storage. It also supports different PostgreSQL environments, including bare-metal servers, Patroni clusters and Kubernetes deployments.

Overall, it was an interesting presentation about an alternative approach to PostgreSQL backups, with a strong focus on simplicity, storage efficiency and reliable recovery.

Patroni the right way

I then attended a session presented by Alexander Kukushkin and Polina Bungina, two of the main contributors to Patroni.
The presentation explained how Patroni really works behind the scenes, with a special focus on automatic failover and the challenges of managing a high-availability PostgreSQL cluster.

One important topic was the risk of split-brain, when two PostgreSQL nodes believe they are the primary at the same time. The speakers explained why a simple two-node setup is not enough and why quorum and fencing mechanisms are important to prevent this situation.
They also explained how Patroni uses a Distributed Configuration Store (DCS), such as etcd, to coordinate the cluster, manage the leader election and keep track of the state of each node.
The presentation also covered some important features, such as synchronous replication, standby clusters and DCS failsafe mode. Finally, they presented some upcoming features, including site-aware failover, which will help Patroni make better decisions when a cluster is spread across several data centers.

This was a very nice session to better understand the internal mechanisms of Patroni and the challenges of building a reliable PostgreSQL high-availability architecture.

Data Quality

Due to meetings with my customers, I unfortunately couldn’t attend any other sessions on Wednesday. However, I just managed to catch my colleague Hervé Schweitzer presentation of our OMrun tool during the “Silver Sponsor Lightning Talks”.

Are you interested in data quality?
Take a look here to learn more about OMrun: https://www.dbi-services.com/fr/produits/omrun/

New communication Hub for the PostgreSQL Community

On Thursday, I attended a session presented by Jack Bonatakis about Hackorum, a tool designed to make PostgreSQL mailing lists easier to use for both experts and newcomers.
PostgreSQL development relies heavily on mailing lists, but following long email discussions can be difficult, especially when there are many messages.
Hackorum provides a modern, forum-style web interface on top of the existing mailing lists. It does not replace them. Instead, it makes discussions easier to read, follow and organize. Some of its main features are:

• Better discussion view: messages are grouped into topics, making long conversations easier to follow.
• Read tracking: you can see which messages you have already read and continue where you stopped.
• Commitfest integration: information about patches and their status is available directly alongside the related discussions.
• Tags, notes and favourites: users can organize discussions, save important topics and add personal notes.
• Team collaboration: reading status, tags and notes can be shared with other team members.

Compared to traditional mailing lists, Hackorum offers a more visual and user-friendly interface. It helps reduce the number of emails to manage and makes it easier to follow several discussions at the same time. The integration with Commitfest is also useful for PostgreSQL developers who want to follow patches and their progress.
One important point is that the mailing lists remain the main source of information. Hackorum simply provides a more convenient way to access and organize their content.

I found this an interesting initiative that could make the PostgreSQL community more accessible, especially for newcomers who may find the traditional mailing lists difficult to follow.

Monitoring

I finished the conference with a presentation by Jimmy Angelakos about radar and radar-analyst, two tools designed to simplify PostgreSQL diagnostics.
The idea behind radar is simple: instead of installing monitoring agents and collecting information over a long period, you can run a single command to collect a snapshot of the PostgreSQL server and its operating system.
The tool is agentless and does not require any additional dependencies. It creates a ZIP archive containing useful diagnostic information, including PostgreSQL configuration, database statistics, replication status, table and index information, as well as system resources such as CPU, memory and disk I/O.

The second tool, radar-analyst, analyzes this archive and helps identify potential problems. It uses predefined rules to check different areas, including PostgreSQL configuration, workload, replication and operating system settings. Each finding includes an explanation and recommendations to help fix the problem.

Compared to traditional monitoring solutions, this approach has several advantages. There is no need to install or maintain an agent, and a diagnostic snapshot can be collected when a problem occurs, even if no monitoring was configured beforehand.

I found this to be a practical approach to PostgreSQL troubleshooting. It can be particularly useful for support teams and DBAs who need to quickly understand the state of a database server without spending hours collecting information manually.