# Patroni replication behaves the same regardless of the value set for synchronous\_mode\_strict **URL:** \ **Category:** Percona Operator for PostgreSQL\ **Tags:** percona\ **Created:** [June 1, 2026, 10:55am UTC](https://forums.percona.com/t/patroni-replication-behaves-the-same-regardless-of-the-value-set-for-synchronous-mode-strict/40856 "2026-06-01T10:55:02Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Srinivas](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/srinivas/32/23606_2.png) [@Srinivas](https://forums.percona.com/u/Srinivas)\ **Post date:** [June 1, 2026, 10:55am UTC](https://forums.percona.com/t/patroni-replication-behaves-the-same-regardless-of-the-value-set-for-synchronous-mode-strict/40856/1 "2026-06-01T10:55:02Z")
Percona Operator Version: 2.8.2 Postgres Version: 16 We have defined the below parameters related to Patroni replication. It is expected that writes will continue when the parameter synchronous\_mode\_strict set to false, is this expected? [root@bastion-node pg-db]# cat values.yaml | grep sync synchronous\_mode: “on” [root@bastion-node pg-db]# oc get pg pg-cluster-ha-pg-db -o yaml | grep sync synchronous\_mode: “on” synchronous\_mode\_strict: false synchronous\_node\_count: 2 syncPeriodSeconds: 10 [root@bastion-node pg-db]# While we are testing sync and async replication between the primary and replica pods, the following is the insert status irrespective of the parameter value “synchronous\_mode\_strict”. - w/ synchronous\_mode\_strict:true - w/ synchronous\_mode\_strict:false ---
**Author:** ![anil.joshi](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/anil.joshi/32/13100_2.png) [@anil.joshi](https://forums.percona.com/u/anil.joshi)\ **Post date:** [June 23, 2026, 5:38am UTC](https://forums.percona.com/t/patroni-replication-behaves-the-same-regardless-of-the-value-set-for-synchronous-mode-strict/40856/2 "2026-06-23T05:38:41Z")
@Srinivas **synchronous\_mode\_strict** maintains strict consistency and requires at least one synchronous replica to allow commits or write request. > This parameter prevents Patroni from switching off the synchronous replication on the primary when no synchronous standby candidates are available. As a downside, the primary is not be available for writes (unless the Postgres transaction explicitly turns off synchronous\_commit), blocking all client write requests until at least one synchronous replica comes up > **[Replication modes — Patroni 4.1.3 documentation](https://patroni.readthedocs.io/en/latest/replication_modes.html)** I tried deleting one of the sync pods [cluster1-instance1-gmx5-0] with --force and observed a few seconds stall on leader write. ```auto sh-5.1$ patronictl list + Cluster: cluster1-ha (7654234399595749491) -------------------------+--------------+-----------+----+-------------+-----+------------+-----+ | Member | Host | Role | State | TL | Receive LSN | Lag | Replay LSN | Lag | +---------------------------+-----------------------------------------+--------------+-----------+----+-------------+-----+------------+-----+ | cluster1-instance1-bv44-0 | cluster1-instance1-bv44-0.cluster1-pods | Replica | streaming | 2 | 0/18000000 | 0 | 0/18000000 | 0 | **| cluster1-instance1-gmx5-0 | cluster1-instance1-gmx5-0.cluster1-pods | Sync Standby | streaming | 2 | 0/18000000 | 0 | 0/18000000 | 0 |** | cluster1-instance1-mwsw-0 | cluster1-instance1-mwsw-0.cluster1-pods | Leader | running | 2 | | | | | +--------------------------- ``` ```auto kubectl delete pod cluster1-instance1-gmx5-0 --force -n postgres-operator Warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely. pod "cluster1-instance1-gmx5-0" force deleted ``` That stall happens because sync replica[cluster1-instance1-gmx5-0] was stopped for that movement. ```auto sh-5.1$ patronictl list + Cluster: cluster1-ha (7654234399595749491) -------------------------+--------------+-----------+----+-------------+-----+------------+-----+ | Member | Host | Role | State | TL | Receive LSN | Lag | Replay LSN | Lag | +---------------------------+-----------------------------------------+--------------+-----------+----+-------------+-----+------------+-----+ | cluster1-instance1-bv44-0 | cluster1-instance1-bv44-0.cluster1-pods | Replica | streaming | 2 | 0/1A0000D0 | 0 | 0/1A0000D0 | 0 | **| cluster1-instance1-gmx5-0 | cluster1-instance1-gmx5-0.cluster1-pods | Sync Standby | stopped | | unknown | | unknown | |** | cluster1-instance1-mwsw-0 | cluster1-instance1-mwsw-0.cluster1-pods | Leader | running | 2 | | | | | +---------------------------+-----------------------------------------+--------------+-----------+----+-------------+-----+------------+-----+ ``` Here, the leader continues waiting for acknowledgements from the sync standby, which was down. Later once it available the writes works fine. ```auto sh-5.1$ patronictl list + Cluster: cluster1-ha (7654234399595749491) -------------------------+--------------+-----------+----+-------------+-----+------------+-----+ | Member | Host | Role | State | TL | Receive LSN | Lag | Replay LSN | Lag | +---------------------------+-----------------------------------------+--------------+-----------+----+-------------+-----+------------+-----+ | cluster1-instance1-bv44-0 | cluster1-instance1-bv44-0.cluster1-pods | Replica | streaming | 2 | 0/1B000000 | 0 | 0/1B000000 | 0 | | cluster1-instance1-gmx5-0 | cluster1-instance1-gmx5-0.cluster1-pods | Sync Standby | streaming | 2 | 0/1B000000 | 0 | 0/1B000000 | 0 | | cluster1-instance1-mwsw-0 | cluster1-instance1-mwsw-0.cluster1-pods | Leader | running | 2 | | | | | +---------------------------+-----------------------------------------+--------------+-----------+----+-------------+-----+------------+-----+ sh-5.1$ ``` The fact is, with that instant delete [–force], it immediately removes resources from the API and bypasses graceful deletion. This most likely doesn’t allow time to switch sync mode on other available Replica [cluster1-instance1-bv44-0] or still the writes consider old Sync node for some time frame. > –force > If true, immediately remove resources from API and bypass graceful deletion. Note that immediate deletion of some resources may result in inconsistency or data loss and requires confirmation. > [kubectl delete | Kubernetes](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_delete/) Your observation is correct. With graceful deletion, it works fine, and we didn’t observe this issue. Can you please share the patronictl output below to take a quick look at the member roles sync staus? ```auto kubectl exec -it -n postgres-operator -- sh patronictl list ```