Postgres Shared Buffers remains one of the most difficult parameters to configure since its inception. Beyond an initial estimate, query patterns, relative storage performance, available resources, and realistic limits can all influence the final value entered here. Or is the picture far simpler than we thought? This is the first in a two-part series discussing the role of shared buffers in the past, and on more modern systems.

What does High Availability actually mean when we’re discussing Postgres clusters? High Availability Architect, Shaun Thomas, explores answers to this question in this week's installment of PGPhriday.

In the wake of Postgres Build 2021, High Availability Architect Shaun Thomas follows up on some of the questions he wasn't able to answer during his session on High Availability.

Frequent participants in the Postgres Discord and Slack servers, mailing lists, IRC chat, and other Postgres hangouts often hear a common refrain: I’ve installed Postgres, so now what? We may be tempted to say “Go forth young one, and explore!” Yet there’s a more fundamental question left unanswered: how do you even connect to explore in any capacity? What does that entail? Let’s explore how to connect to a fresh Postgres installation, and see what a new user really needs to know in order to experiment with Postgres.

High Availability is more than just choosing the right architecture, replication tools, and failover systems. Storage can play a surprisingly important role in server responsiveness, as can somewhat obscure operating system tuning parameters. This week in PG Phriday, we’re going to examine just how important storage behavior can be to Postgres High Availability.

Hot on the heels of our discussion on preventing Postgres XID wraparound using basic monitoring, let’s talk about arresting the risk almost entirely through Autovacuum. With a few relatively minor tweaks to our configuration and focusing on the occasional problematic table, we can both increase maintenance throughput, and also reduce impact on client queries. Let’s demystify the art of VACUUM and keep our cluster self-maintaining in the bargain.

Since transactions and replication within Postgres are essential to all types of availability, that means keeping the transaction ID state healthy. This Phriday we’ll cover the best configuration settings for avoiding this and take a look at what kind of monitoring we can employ as an early warning system. Don’t let the prospect of Postgres XID wraparound make you dizzy!

The types of Postgres clusters we can build to achieve high availability is highly dependent on the replication technologies we employ, both now, and in the future. Let’s explore how Postgres replication evolved to what it is today, and how it could grow in the future. By understanding this, we can design clusters that take full advantage of the tools Postgres makes available, and be ready for coming enhancements.

Join us this week as we share a dire warning against misusing pglogical in an attempt to achieve bi-directional replication. The end result will likely incur data loss, node divergence, system outages, and be far more of a potential liability than many would expect. From additional necessary management scripts to maintain the facade, to unhandled conflicts mixing data, we’ll discuss just a few of the ways this seemingly innocent attempt at innovation can go wrong.

High Availability Architect, Shaun Thomas, explores options for tools that boost the high-availability functionality of Postgres.