PGConf.Russia 2025

Last year, we introduced built-in fault tolerance support in Postgres Pro Enterprise through BiHA. Our solution allows you to deploy a fault-tolerant Postgres cluster where, in the event of a failure of the primary node, a new primary node (leader) is automatically selected.

However, this brings up the issue of redirecting traffic to the new leader. This can be solved using our Proxima extension or an external TCP proxy server. Both solutions needed to periodically query the BiHA cluster to determine the primary node.

As an alternative, the latest version of BiHA introduced the ability to register custom functions that will be triggered by events such as leader change, node addition/removal, and others. We call this mechanism user callbacks. In this presentation, we’ll explain how the callbacks are implemented and discuss their usage.

Covering all the key changes in PostgreSQL 18 during this talk would be quite a challenge — especially since the code freeze is set to happen just a week after the presentation. However, I’ll focus on what has already been finalized.

There are plenty of exciting updates in performance, monitoring, vacuuming (of course!), and beyond. As always, this talk is based on a series of articles reviewing the commit fests for PostgreSQL 18, published on Postgres Professional’s corporate blog on Habr.

In this session, we’ll provide an overview of the features of the pg_probackup3 backup utility. 

The new version has completely rethought the application architecture, introduced several long-awaited features, and added integration possibilities with other applications. We’ll dive into these updates and discuss them in detail during the presentation.

Making changes to tables under production load is always a complex task. For example, when you need to change a column type (e.g., from int to bigint or from timestamp to timestamptz), or move a table to a different tablespace without losing any changes that occur during the data migration.

What if you have hundreds of such tables? With pg-transparent-alter-table, this is no longer a problem. These tasks can be solved with a single simple command:
$ pg_tat -h 0.0.0.0 -d mydb -c "alter table mytable alter column id bigint"

Key features include:

• You can specify any number of alter table commands at once.
• You can modify partitioned tables, supporting both the old inheritance-based partitioning and new declarative partitioning, including multi-level partitioning.
• You can interrupt the process at any stage and continue later without losing progress from previous stages.
• You can change your mind at any time, stop the execution, run "pg_tat --clean," and revert to the original state.
• Custom commands for changing column order.
• PostgreSQL version support: 11-17.

After more than 5 years of existence (previously called transparent-alter-type), the project has become a reliable tool actively used in production. I would like to share my experience and discuss its capabilities.