“Acknowledged by a standby” needs a precise stage. Under PostgreSQL synchronous_commit = remote_write, a commit waits until a synchronous standby has received the WAL and written it to its operating system, but that standby has not necessarily flushed it to durable storage. An OS-level crash can lose those buffered bytes. With synchronous_commit = on and a correctly configured synchronous standby, the remote WAL flush is part of the wait. remote_apply also waits for replay so standby reads can see the change. PostgreSQL's WAL configuration documentation distinguishes these modes. Remote visibility, remote write and remote durability are not one event.

Here is one possible timeline. The primary flushes and reports success after a remote_write acknowledgment. The primary's storage then becomes unavailable, and the same standby suffers an operating-system crash before it durably flushes that WAL. Promote the recovered standby, and the transaction can be absent. Another route is promoting a different lagging standby from the one that acknowledged the commit. Even remote flush on one node does not make every possible failover target safe. Check the configured synchronous standby names and which node actually acknowledged each commit.

I would trace the primary commit LSN, standby write, flush and replay LSNs, actual failover candidate, promotion timeline, and whether the old primary can later rejoin safely. Verify that the lost write was truly acknowledged to the client and that the application did not confuse an asynchronous job acceptance with a database commit. Test a failover under the precise mode, including OS-level crash and a lagging alternate standby. PostgreSQL's standby documentation explains remote-write durability and replication-delay loss during failover.

If the business cannot lose an acknowledged policy or payment record, choose a stronger commit and promotion policy, then pay the latency and availability cost when the required standby is unreachable. If the standby can answer reads immediately after commit, that is a separate visibility question requiring replay, not merely WAL flush. The policy update succeeded. Why did the next read return the old rule? is a stale follower read after a committed primary write. Kafka acknowledged the event. Why did it vanish after the leader failed? is Kafka acks-one loss on leader failure. This case requires naming both the acknowledgment stage and the standby that may be promoted.