PgConf.Russia 2020

Patroni and Stolon are two of the most popular and advanced solutions for orchestrating PostgreSQL and ensuring auto-failover for clusters with the Leader-Followers configuration. However, engineers who migrate from good old tools like Corosync&Pacemaker or built-in solutions of other DBMS often run into issues when installing these tools and figuring out the purpose of each component.
In this tutorial, we will go through a typical installation procedure of Patroni and Stolon clusters on virtual machines (not in containers), as well as review their behavior in case of various infrastructure failures. The whole process will be demonstrated on three vagrant virtual machines with pre-built images. You can follow along on your own system if you set up the required environment.

Tracking poor queries is an infinity quest for developers, who works with databases. Often we think that it is guilty the slow and big queries. But what to do if we do not have that kind of queries between backend and database? Which kind of queries should we looking for? What tools should be used for that work? This talk will cover all these questions.

Recently, I was working on a project where graphQL was used for sending requests to its .NET Core backend, but this was not a good idea. The point is, a graphQL query is a hierarchical structure with a dynamic set of fields. It’s difficult to perform such requests via a statically-typed programming language and a relational database as suggested by the tools available. So, I came up with the idea of using the plv8 extension and perform graphQL queries right on the database side. It took me about two hours to develop a working prototype that could perform the same queries as the software under development for more than one month! Then various improvements have been made and I want to introduce them all. If you are thinking of using graphQL instead of REST, my speech could be most useful and could help you to save a lot of time.

PostgreSQL 13 Feature Freeze is scheduled for April 2020. Two more commitfests are still accepting new patches. What we can say about PostgreSQL 13. It's possible that rotation rule will work so that new release wouldn't have as many new features as PostgreSQL 12 have. If even it is do, that would be good evolutionary release with a lot of medium feature and infrastructure changes, which prepares postgres for new leap. In this talk I will overview expected novelties in PostgreSQL 13. It would be more or less accurate, since there would be only one commitfest left, which results are possible to forecast.