The session ended with a look at how to recover disk space in tables after autovacuum has cleaned them up, especially with Speaking about I then attended a session about <\/p>\n\n\n\n I then attended a session presented by Alexander Kukushkin and Polina Bungina, two of the main contributors to Patroni. 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\u00e9 Schweitzer presentation of our OMrun tool during the “Silver Sponsor Lightning Talks”.<\/p>\n\n\n\n Are you interested in data quality? On Thursday, I attended a session presented by Jack Bonatakis about Hackorum<\/a>, a tool designed to make PostgreSQL mailing lists easier to use for both experts and newcomers. 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. I finished the conference with a presentation by Jimmy Angelakos about 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 […]<\/p>\n","protected":false},"author":30,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[83],"tags":[1449,1063,4286,3206,2602],"type_dbi":[],"class_list":["post-48142","post","type-post","status-publish","format-standard","hentry","category-postgresql","tag-conference","tag-feedback","tag-pgconf","tag-pgconf-eu","tag-postgresql-2"],"acf":[],"yoast_head":"\nREPACK<\/a><\/code>, which also has a CONCURRENTLY<\/code> option that allows other transactions to use the table while it is being repacked.<\/p>\n\n\n\nZero downtime?<\/h2>\n\n\n\n
REPACK<\/code>, this new feature was also presented by Rajni Baliyan during her presentation about how to achieve zero downtime with PostgreSQL 19.REPACK CONCURRENTLY<\/code> allows tables to be reorganized and disk space to be recovered without blocking normal database operations for the entire process. Unlike VACUUM FULL<\/code>, which blocks access to the table during the operation, REPACK CONCURRENTLY<\/code> 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<\/a><\/code> 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.<\/p>\n\n\n\nModern Backups for PostgreSQL<\/h2>\n\n\n\n
pg_hardstorage<\/a><\/code>, presented by Hans-J\u00fcrgen Sch\u00f6nig.pg_hardstorage<\/code> 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<\/code> 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.<\/p>\n\n\n\nPatroni the right way<\/h2>\n\n\n\n
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<\/em>, 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.<\/p>\n\n\n\nData Quality<\/h2>\n\n\n\n
![\"\"](\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2026\/10\/PXL_20261021_140030609-1024x576.jpg\")
<\/figure>\n\n\n\n
Take a look here to learn more about OMrun: https:\/\/www.dbi-services.com\/fr\/produits\/omrun\/<\/a><\/p>\n\n\n\nNew communication Hub for the PostgreSQL Community<\/h2>\n\n\n\n
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:<\/p>\n\n\n\n\n
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.<\/p>\n\n\n\nMonitoring<\/h2>\n\n\n\n
radar<\/a><\/code> and radar-analyst<\/a><\/code>, two tools designed to simplify PostgreSQL diagnostics.
The idea behind radar<\/code> 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<\/code>, 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.<\/p>\n","protected":false},"excerpt":{"rendered":"