Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ozXhk-0003F4-05 for pgsql-hackers@arkaria.postgresql.org; Mon, 28 Nov 2022 06:33:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ozXhi-0000ja-AD for pgsql-hackers@arkaria.postgresql.org; Mon, 28 Nov 2022 06:33:22 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ozXhh-0000jR-Vs for pgsql-hackers@lists.postgresql.org; Mon, 28 Nov 2022 06:33:22 +0000 Received: from mail-wr1-x42c.google.com ([2a00:1450:4864:20::42c]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ozXhf-0003oT-Hu for pgsql-hackers@lists.postgresql.org; Mon, 28 Nov 2022 06:33:20 +0000 Received: by mail-wr1-x42c.google.com with SMTP id w15so1929464wrl.9 for ; Sun, 27 Nov 2022 22:33:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=KKtSPuDVPnmoYbA+bznTxdnBFTXYI62tFRKzFK1AwMU=; b=QXb6cuJ+i4PkqTgdaSbasEc6MArSmKyeM0QbC8Ow74ZPfiEbXwS90nqkySMJ6WwYpL B8g+ZFxkPF+ZOj1YvUMWsB4koH6MbsOLmKqaVNHsbwU1En+myIsplXqPMd1hSKzegA5w QoKOM/Hov1c0ZkVweIh3VsGxurK0BHKuX5CWP6jpToIys4wrUtqFYnX1cdx4Ct8JkrYc qQg9RDErf7HIQaOk4MFE5Nc60KIy4FJukUbkRraoVlUFAUBEczBwwrxw313EyHT5Azbk 92VV7+HdwxvNvP3S60FscYozUSLfrVdnoR/UlBu6K/8AAIrjbhOyorEfev5gnt7Y2V6h 7a7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KKtSPuDVPnmoYbA+bznTxdnBFTXYI62tFRKzFK1AwMU=; b=ZR0WIuAvmG0WbLPDMDedRIIla+JOcPHOtalvgbwwe0JKuprOR2zpKImWFo8KbgsHMY DYku+ZqPqzlwdryLI3CGAzFT/rc0ilCl6HhqhkEDgt+mQ/BvFetMNpOXcwySmVosv6LS nxfGXoPxm79nSbGdGFwnQ4N5LxiPxnQRGtKmOpXpKPTpaOgb4itvw3LTWXuSFpbSrprT bGSPa1q4W1TFUdftil6CsaO3+Fvx2xgaYCPysgzlY30eROS9tZFPtLHG/9xvfrbCofaX lgu0MTuTqUoeplocaB1uHiVFp8WpSn/KUDkepf5xMvddWG+JS+mbrAvcblowf97saPGp H1Kg== X-Gm-Message-State: ANoB5pn78NHf5X8Bz4A6NhjgX0GMCtNtwufxaAj+IC5d0f9yye8onPb/ aqpGFp1uaTXzdwZGdh086MbbUQyM+8ar3y5cy/s= X-Google-Smtp-Source: AA0mqf77ZWF1S2I7Si2zirlGsEm5KbLP4iCsYbNPJYML1ht1M6Nk3aJW3p5DPVkU9OfG/38IVYhSQR/zRcr9//c6fdc= X-Received: by 2002:a5d:4344:0:b0:22e:3430:475d with SMTP id u4-20020a5d4344000000b0022e3430475dmr30582261wrr.65.1669617198168; Sun, 27 Nov 2022 22:33:18 -0800 (PST) MIME-Version: 1.0 References: <9290b55b6ae2b04e002ca9dadadd1cca09461482.camel@cybertec.at> <20220805.114916.994654810780821553.horikyota.ntt@gmail.com> <20220809.161236.1486509314201074910.horikyota.ntt@gmail.com> In-Reply-To: From: Bharath Rupireddy Date: Mon, 28 Nov 2022 12:03:06 +0530 Message-ID: Subject: Re: An attempt to avoid locally-committed-but-not-replicated-to-standby-transactions in synchronous replication To: Andrey Borodin Cc: Bruce Momjian , Kyotaro Horiguchi , Laurenz Albe , PostgreSQL Hackers , SATYANARAYANA NARLAPURAM Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, Nov 28, 2022 at 12:57 AM Andrey Borodin 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. 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. -- Bharath Rupireddy PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com