PGConf.Russia 2025

In any business-critical system, there comes a need to modify table structures — whether it's adding new columns with expressions based on other columns or converting a non-partitioned table into a partitioned one.

Using standard PostgreSQL tools for large table reorganization often results in significant downtime, as tables become unavailable for writes — and sometimes even for reads — during the process.

In this talk, I’ll introduce dbms_redefinition, a custom-built extension that brings functionality similar to Oracle’s DBMS_REDEFINITION package to PostgreSQL. This solution minimizes downtime to near zero when applying schema changes in production. 

Unlike pg_repack, which does not support structural modifications, dbms_redefinition is useful for all PostgreSQL users, even beyond Oracle migrations.

I’ll share a real-world use case, discuss future development plans, and explore new features in the pipeline.

This talk will likely be of interest to network providers who can enhance their cool features by adding something to the syntax to simplify administration, as well as anyone interested in machine learning. We will explore the SQL parsing mechanism, what, where, and how to modify it in order to introduce new syntax constructs. Additionally, I will demonstrate the capabilities of machine learning on tabular data, all within the database, using the new syntax.

This presentation examines the challenges of migrating an application system from Oracle to Postgres, based on a real-world project. It provides a detailed discussion on logical replication of data from Postgres to ensure the possibility of reverting back to Oracle while maintaining the functionality of legacy reporting and integration.

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.