Possible issue where synchronous_mode_strict does not appear to affect commit behavior during synchronous standby loss

PostgreSQL Percona Operator for PostgreSQL
1

Description:

We are testing synchronous replication behavior in a Kubernetes deployment managed by Patroni (deployed via Percona PostgreSQL Operator).

Our cluster consists of:

  • 1 Primary

  • 1 Replica

Configuration:

synchronous_mode: "on"
synchronous_mode_strict: true
synchronous_node_count: 1

We performed tests with both:

synchronous_mode_strict: true

and

synchronous_mode_strict: false

and observed identical behavior in both cases.

This raises two questions:

  1. When the only synchronous standby is gracefully terminated, we would expect commits on the primary to stall because no synchronous standby is available. However, if Patroni intentionally recognizes a graceful, administratively initiated shutdown and proactively reconfigures synchronous replication to avoid blocking commits, then this behavior may be expected. We would like confirmation of whether this is indeed the intended behavior.

  2. More importantly, the observed behavior is identical regardless of whether synchronous_mode_strict is set to true or false. Based on our understanding, this parameter should influence commit behavior when synchronous standbys become unavailable. The fact that we observe no difference makes it appear that synchronous_mode_strict is not having any practical effect in this scenario.

Steps to Reproduce:

  1. Deploy a Patroni-managed PostgreSQL cluster with:

    • 1 Primary

    • 1 Replica

  2. Configure:

    synchronous_mode: "on"
synchronous_mode_strict: true
synchronous_node_count: 1

  3. Generate write transactions against the primary.

  4. Gracefully delete the replica pod:

    kubectl delete pod <replica-pod>

  5. Observe commit behavior on the primary.

  6. Recreate the replica and verify replication is healthy.

  7. Force delete the replica pod:

    kubectl delete pod <replica-pod> --force --grace-period=0

  8. Observe commit behavior on the primary.

  9. Repeat the above tests with:

    synchronous_mode_strict: false

Version:

  1. Patroni Version: 4.1.0
  2. PostgreSQL Version: 16
  3. Percona PostgreSQL Operator Version: 2.8.2
  4. Kubernetes Version: OCP 4.18

Logs:

Logs from Primary:

2026-05-26 14:31:09,979 INFO: Lock owner: pg-cluster-ha-pg-db-pgsa-jmhg-0; I am pg-cluster-ha-pg-db-pgsa-jmhg-0

2026-05-26 14:31:09,993 INFO: Updating synchronous privilege temporarily from [‘pg-cluster-ha-pg-db-pgsa-kq2l-0’] to []

2026-05-26 14:31:10,004 WARNING: No standbys available!

2026-05-26 14:31:10,005 INFO: Assigning synchronous standby status to [‘*’]

server signaled

2026-05-26 14:31:10,050 INFO: no action. I am (pg-cluster-ha-pg-db-pgsa-jmhg-0), the leader with the lock

2026-05-26 14:31:19,980 INFO: Lock owner: pg-cluster-ha-pg-db-pgsa-jmhg-0; I am pg-cluster-ha-pg-db-pgsa-jmhg-0

2026-05-26 14:31:19,994 WARNING: No standbys available!

2026-05-26 14:31:19,994 INFO: Assigning synchronous standby status to [‘*’]

2026-05-26 14:31:20,033 INFO: no action. I am (pg-cluster-ha-pg-db-pgsa-jmhg-0), the leader with the lock

2026-05-26 14:31:29,980 INFO: Lock owner: pg-cluster-ha-pg-db-pgsa-jmhg-0; I am pg-cluster-ha-pg-db-pgsa-jmhg-0

2026-05-26 14:31:29,992 INFO: Assigning synchronous standby status to [‘pg-cluster-ha-pg-db-pgsa-kq2l-0’]

server signaled

2026-05-26 14:31:32,117 INFO: Synchronous standby status assigned to [‘pg-cluster-ha-pg-db-pgsa-kq2l-0’]

Expected Result:

For graceful deletion:

  • If Patroni intentionally treats a graceful replica shutdown as an administrative action and dynamically adjusts synchronous replication configuration, then commits continuing on the primary would be understandable.

  • We would like confirmation whether this is the intended design.

For force deletion:

  • The primary should block commits when no synchronous standby is available and synchronous_mode_strict=true.

For synchronous_mode_strict:

  • We expect observable behavioral differences between synchronous_mode_strict=true and synchronous_mode_strict=false when the only synchronous standby becomes unavailable.

Actual Result:

With synchronous_mode_strict=true:

Graceful replica deletion:

  • Replica shuts down.

  • Primary continues accepting writes and commits (logs indicate synchronous_standby_names status being set to [*])

Force replica deletion:

  • Primary stalls and commits are blocked.

With synchronous_mode_strict=false:

Graceful replica deletion:

  • Replica shuts down.

  • Primary continues accepting writes and commits.

Force replica deletion:

  • Primary stalls and commits are blocked.

The observed behavior is therefore identical regardless of the value of synchronous_mode_strict.

Additional Information:

The primary questions are:

  1. Is Patroni intentionally reconfiguring synchronous replication during graceful standby shutdown, thereby allowing commits to continue even when the only synchronous standby is being removed?

  2. If so, why does the observed behavior remain unchanged when switching synchronous_mode_strict between true and false?

  3. Under what failure or operational scenarios is synchronous_mode_strict expected to produce behavior different from synchronous_mode_strict=false?