PGConf.SPB 2023

Fuzzing research is feeding random input data to a program (or a part of it) (in fact, randomness is very conditional) and seeing what we get out of it. And we repeat it many times on many processors.

Fuzzing a large monolithic program complex is never a simple task. It requires extraordinary solutions. In this talk, I will tell you what and how we searched with the help of fuzzing and what results it led to.

• Investigation of data type parsing functions (input-functions): for warming up;
• Investigation of functions implementing operations between types (op-functions): it is better to consider the structure here;
• Network subsystem fuzzing: let's pretend we are POSIX calls, it's cheaper that way;
• Recovering disk context: we need Groundhog Day.

A story about funny bugs and ridiculous hand gestures will be included.

Traditionally, fault tolerance in Postgres is implemented using built-in replication mechanisms and external utilities that monitor the state of running Postgres instances and react accordingly when various failures occur. In this presentation, I will tell you what we like and what we don’t like about this approach, which alternative we see, what we have been able to achieve to date and what we want to get done by the time of release, which is planned for December.

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.