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 1ozNIx-0003uF-Tx for pgsql-hackers@arkaria.postgresql.org; Sun, 27 Nov 2022 19:27:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ozNIv-0004n7-98 for pgsql-hackers@arkaria.postgresql.org; Sun, 27 Nov 2022 19:27:05 +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 1ozNIu-0004kX-UO for pgsql-hackers@lists.postgresql.org; Sun, 27 Nov 2022 19:27:05 +0000 Received: from mail-yw1-x112a.google.com ([2607:f8b0:4864:20::112a]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ozNIs-0006bS-Rd for pgsql-hackers@lists.postgresql.org; Sun, 27 Nov 2022 19:27:03 +0000 Received: by mail-yw1-x112a.google.com with SMTP id 00721157ae682-3b56782b3f6so86303287b3.13 for ; Sun, 27 Nov 2022 11:27:02 -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=MNBoYmXlnBGvzOOfHJfVlYImaJCUYbVwfjNEAIwqcdg=; b=iK4UJx4HMbJ4faudArp5+y5429gZK+hDt0M2k+w7sjCs0a+ys//Oc4mDpaxbXt3od0 mBiMffb8RoWc8BGx//Pk1XCfJRo2CES7yALfkIU8Yq9/7k5+YckoPyGCnyFUW6FQbLl7 kLHD65REh8AIEthX1DVXZJKAXYx2sHAcQPOarAe+gclrn2Hx+UIDfIj/IfI2PrtCLRPw shtbEnTGNGHHpDAYlHD7V2i20qiI6OBtzhUv2wf32ujM7jxv1vpu/FDeLFGKlz5zseXj Uf1vHNDz79FvJEKDQeoURytPmcbCyz+Smmosw/VGaIaoJirrLqwbbUI+FemHhEqN0K2k MCnw== 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=MNBoYmXlnBGvzOOfHJfVlYImaJCUYbVwfjNEAIwqcdg=; b=l6+hxsaq15ttoltBezdOS/7hBB9J8+v8XfdWacF9HZm3zpiQyjJqQMQXMkNiF+X/hA REgEyAYl11fmj4ELnrSl5mv53rYD/OoO8l8WhxYcgwukWF1lrPZD9TQ4xRKgHLfxNZ+A GiEYwqvqGEJZWDp8ewhlSU5MoY3wdzgparemQvrZaSbMS6JeD2Hrgh+TyrOD9gnyoD4f keHeVCRl8+lPgsJ6eEnImXpgUVG7OfHqSMGulKrGMicUijmRMlP+QNixgdX82jbgYlWt pI7UqYPtUY0nwiKRCSJRJG5YttD+xzZ7pHamn7y+yiDT05K7u7PgNscucGAr6W63a6B+ SI6A== X-Gm-Message-State: ANoB5pmtfrj4PtFKNUBVdAihLLhra/5Gm7JFPc8EyDcBb+J87QSPqT+d iYZxjT8LRgl/8I6VDCYO79FYyOEgGr8GKIJZ81k= X-Google-Smtp-Source: AA0mqf7lxPTuKNUqsuCIJkseZ025L2/CYgx/hfjgqM3+c58aVRqBxVldsylv4608GRFw59ESlw73fPO+F0OXcXbR3BM= X-Received: by 2002:a81:1615:0:b0:3b9:b07a:c234 with SMTP id 21-20020a811615000000b003b9b07ac234mr12699583yww.518.1669577221525; Sun, 27 Nov 2022 11:27:01 -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: Andrey Borodin Date: Sun, 27 Nov 2022 11:26:50 -0800 Message-ID: Subject: Re: An attempt to avoid locally-committed-but-not-replicated-to-standby-transactions in synchronous replication To: Bruce Momjian Cc: Bharath Rupireddy , 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 Tue, Nov 8, 2022 at 9:06 PM Andrey Borodin wrote: > > On Thu, Sep 29, 2022 at 3:53 PM Bruce Momjian wrote: > > > > So, what happens when an insufficient number of synchronous replicas > > reply? > > It's a failover. > > > Sessions hang because the synchronous behavior cannot be > > guaranteed. We then _allow_ query cancel so the user or administrator > > can get out of the hung sessions and perhaps modify > > synchronous_standby_names. > > Administrators should not modify synchronous_standby_names. > Administrator must shoot this not in the head. > 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. Best regards, Andrey Borodin.