GitOps pg_parameters and patronictl

[VadimJCA]

In my attempt to tidy up management of a swarm of PostgreSQL clusters by moving onto pgsty, I took it as and IaC project and steered towards GitOps scenario.

When the time came to configure logical replication as our CDC backbone, thankfully in the staging environment at first, I've found out that many parameters can't be configured through pg_parameters in the inventory. They are, while successfully getting through to postgresql.auto.conf, are being ignored by patroni.

So I can't change things like max_connections or pin slots to patroni by editing an inventory and applying pgsql.yml playbook with some tags like pg_config,pg_param,pg_reload,patroni_config,patroni_reload,pg_restart.
I'll get
2026-02-02 19:04:11 +0500 INFO: PostgreSQL configuration parameters requiring restart (max_connections) seem to be changed bypassing Patroni config. Setting 'Pending restart' flag

I've seen here that The author encourages us to use patronictl often. But doesn't that kill the appeal? As the maintenance quickly devolves back to manual intrusions over SSH.

Am I missing something about maintaining GitOps for patroni config or this is intended behaviour?

[Vonng]

Great question, and I understand the frustration when GitOps expectations meet Patroni's design philosophy.

The Core Issue: Patroni Owns Cluster-Level Parameters

Especially like max_connections, shared_buffers, wal_level, etc. are fundamentally cluster-level settings that Patroni intentionally controls through DCS (etcd). When you write directly to postgresql.auto.conf, Patroni detects this as "bypassing" its authority—hence the Pending restart warning. This is by design, not a bug.

What pg_parameters Is Actually For

The pg_parameters in inventory isn't meant for routine parameter tuning. It's designed for instance-level differentiation—e.g., setting different work_mem on a reporting replica vs. the primary. For cluster-wide parameters, Patroni is the intended control plane.

You Don't Need SSH

Patroni exposes a REST API, so you can manage configurations without SSH:

bash

patronictl -c /pg/bin/patroni.yml edit-config <cluster>

Or use the pig CLI which wraps the Patroni API with simpler commands:

• pt config - view/edit cluster configuration
• Docs: https://pigsty.cc/docs/pig/pt/#pt-config

This keeps operations centralized and auditable.

The Honest Answer

Patroni has effectively "taken over" PostgreSQL parameter management for HA clusters. Pigsty respects this boundary rather than fighting it. For true GitOps over Patroni config, you'd need to version-control your patronictl edit-config changes and apply them via API calls in your CI/CD pipeline.

One More Thing

The recently introduced etcd_fdw extension might help—you could query DCS directly from SQL to audit/verify actual cluster configuration state, which could feed into your GitOps reconciliation logic.

[VadimJCA]

Thank you for explaining! For now, I just vibed up an Ansible role and a playbook that calls patronictl on target and reuses pg_parameters dictionary, since I intend to keep all nodes in a cluster equal in case of failover.