On Mon, Nov 28, 2022 at 12:57 AM Andrey Borodin <amborodin86@gmail.com> wrote: > > Some funny stuff. If a user tries to cancel a non-replicated transaction > Azure Postgres will answer: "user requested cancel while waiting for > synchronous replication ack. The COMMIT record has already flushed to > WAL locally and might not have been replicatead to the standby. We > must wait here." > AWS RDS will answer: "ignoring request to cancel wait for synchronous > replication" > Yandex Managed Postgres will answer: "canceling wait for synchronous > replication due requested, but cancelation is not allowed. The > transaction has already committed locally and might not have been > replicated to the standby. We must wait here." > > So, for many services providing Postgres as a service it's only a > matter of wording.
Thanks for verifying the behaviour. And many thanks for an off-list chat.
FWIW, I'm planning to prepare a patch as per the below idea which is something similar to the initial proposal in this thread. Meanwhile, thoughts are welcome.
1. Disable query cancel/CTRL+C/SIGINT when a backend is waiting for sync replication acknowledgement.
+1
2. Process proc die immediately when a backend is waiting for sync replication acknowledgement, as it does today, however, upon restart, don't open up for business (don't accept ready-only connections) unless the sync standbys have caught up.
Are you planning to block connections or queries to the database? It would be good to allow connections and let them query the monitoring views but block the queries until sync standby have caught up. Otherwise, this leaves a monitoring hole. In cloud, I presume superusers are allowed to connect and monitor (end customers are not the role members and can't query the data). The same can't be true for all the installations. Could you please add more details on your approach?
-- Bharath Rupireddy PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
