PGConf.SPB 2023

Unfortunately, ideal computer systems exist only in science fiction books. PostgreSQL is not exception and sometimes problems may occur. I would like to discuss how to correctly (and incorrectly) try to solve a problem, which way to choose, which tool to use.

The talk is of interest to both beginners and experienced users and database administrators.

During the years of its existence, Postgres Pro piled up a pool of problems when query execution was inappropriately slow or a query was too expensive to be executed, so it was never executed. Almost always in our practice, this was due to the choice of a non-optimal query plan. In our story, we will talk about a very unconventional attempt to solve this problem by re-planning queries. We will tell you what it is, how it works, who will find it helpful and the prospects for using this feature.

We'll talk about the tool we created, which monitors changes in the database and creates scripts for migrations of selected objects both interactively and automatically.

One of the requirements for the operation of the Corosync/Pacemaker failover cluster is the fencing of the failed node. In virtual environments, fencing is implemented by disabling the virtual machine through a hypervisor, in a cluster on physical servers - through IPMI/ILO. But what if it is impossible to organize fencing, for example, in the cloud environment? During this presentation, I will list and explain alternative methods of fencing a failed node.