PGConf.Russia 2021

The pgpro_scheduler extension has an interesting but little-known feature - one-time jobs. Despite its simplicity, this feature can be used for complex transaction processing. On the one hand, it helps to reliably execute tasks taking a very long time, on the other hand, it ensures app scaling if certain conditions are met.

When PostgreSQL was at its formation stage, its transaction ID was chosen to be 32-bit. Back then, no one could imagine that someday we may need more than 4 billion transactions. However, ongoing technical progress and digitization pushed some Postgres instances towards their transaction ID limit. The Postgres community reacted to this with a wraparound of the transaction ID counter. However, constantly growing data volumes exposed PostgreSQL to new challenges. In my presentation, I will cover these challenges and explain how they can be solved with a 64-bit transaction ID, what the consequences will be like, why now it is a good time to implement 64x IDs, and why this hasn't been done previously.

Narrow way to four nines. Postgresql clusterin in virtual environment - why's and how's. Why Corosync/Pacemaker? What about backups? Difficulties, problems and how to avoid them.

We'll discuss our approaches to picking technical solutions for the systems we design. We'll consider their advantages and limitations. We'll share the facts about the changes in our engineering culture when import substitution requirements came into effect. We migrated the system with a classical three-tier architecture from Oracle to Postgres Pro DBMS. In my presentation I'll pay attention to data migration tools and peculiarities of development Java/Kotlin apps and SQL interoperability between two DBMSs.