How to define multiple primaries in pgcat config (pgcat.toml)

[sibodapati]

Hi Team,

We are evaluating pgCat 1.3.0 with a 3-node pgEdge (Spock) multi-master PostgreSQL cluster, where all database nodes are writable and actively replicating with each other.

Our current understanding is that pgCat requires exactly one server to be defined as primary and the remaining servers as replica within a shard.

We have a few questions:

Does pgCat support a true multi-primary / multi-master topology where multiple servers in the same shard can be configured as writable nodes?
If multiple primary entries are not supported, what is the recommended architecture for using pgCat with pgEdge/Spock multi-master clusters?
When the configured primary node becomes unavailable, can pgCat automatically redirect write traffic to another healthy node, or is a manual configuration change required?
Is there any built-in health check, failover, or automatic role reassignment capability for multi-master environments?
Are there any examples, reference architectures, or best-practice configurations for deploying pgCat in front of a pgEdge/Spock multi-master cluster?
If automatic failover is not currently supported, is this functionality on the product roadmap?
For a multi-master cluster where all nodes are writable, what is the recommended way to achieve high availability for application connections through pgCat?

Any guidance or documentation specific to pgEdge/Spock multi-master deployments would be greatly appreciated.

Thank you.

[sueun-dev]

Short answer: no, pgcat caps it at one primary per shard. I tried a shard with two primary entries on 1.3.0 and it refused to start: Shard postgres has more than one primary configured, Config parse error: BadConfig, exit 78. The check lives in Shard::validate() in src/config.rs, it counts roles and errors out when primary_count > 1.

So there's no multi-master write path inside pgcat itself, and since you can't add a second writable node to the shard, there's no automatic write failover or role reassignment either. The banlist health checks cover read/replica failover, not primary promotion.

For Spock/pgEdge where every node is writable, the usual setup is one pgcat shard pointed at a single node with HA fronting that endpoint. Whether real multi-primary support lands later is a maintainer call, not something I can speak to.