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 1noKbv-0003sm-Lp for pgsql-hackers@arkaria.postgresql.org; Tue, 10 May 2022 07:48:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1noKbt-0008Fa-HT for pgsql-hackers@arkaria.postgresql.org; Tue, 10 May 2022 07:48:45 +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 1noKbt-0008FR-5z for pgsql-hackers@lists.postgresql.org; Tue, 10 May 2022 07:48:45 +0000 Received: from mail-oa1-x32.google.com ([2001:4860:4864:20::32]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1noKbm-0000d5-FU for pgsql-hackers@lists.postgresql.org; Tue, 10 May 2022 07:48:44 +0000 Received: by mail-oa1-x32.google.com with SMTP id 586e51a60fabf-d39f741ba0so17334950fac.13 for ; Tue, 10 May 2022 00:48:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jiF9QSlH/XI8U0ynoHTIRhuCknBmdVoiPxQWym1Flq4=; b=qZE4XnxLLcVaCeYpJUVjqLVcytPy8mBcyPOJtniRJi0NIgcG7qik6NdqjpYzkWlHzQ 9cXHnnwza0UtxQ3tggywItFdZOJO8yMhjRXGQFIwwr4B9h+TH3sivoDHbkxcyw402amI EZPUAPhsb4B0F58YYFys11h7UzEbmWox1HQom7Y3tVpsc9hQfw0blJRpFLwnarcEWeSq fjzFO3ZJZ3z6eCcOdnwE5/tiqTWX/itPMI4zH2WW4nF/1kVl9+5sLTjwGQEXXgz01mj9 myo4Nuyg2GVVSSQx34iqqN+FnadJZMilx7knfs50wJXI9//6/ggoUxZYHq2q8Re/Ttvf URTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jiF9QSlH/XI8U0ynoHTIRhuCknBmdVoiPxQWym1Flq4=; b=aePKw0/pWd61Y+qV1MEaezMLShamptzgoElkMF8kxTXwH0XO9xuiN3zbCWbfNmFYNX VJsr4FScMC0BsKOhEazY+8ErpDEAxRUNxjOMNQyRSNgVwIwRJcFUVzlOP3/ma+YrSSTT 40ZlMgLTXIpLk9fYSo/YwhEpFpYDCK0TFBCax8J7Tj13vqaQwfpqBtxD1BP4/ZmEbUPD jSJ5JalYzquXMzoLzoZKiArZ+XkxNzW8ygucj/ekUZ9cYKFeLs3PCxDO7nUiN9OIaMKb 9QHyAX+QSwe4s+YKlKDD6yrdFrfWwVyxnafiRIGmLcr064gS3oulAJo+BuO7rH081cvS bKPA== X-Gm-Message-State: AOAM53010pOmZP9oJwpkEbrIBrSwg4CkFo68h1LOxPaaWoMZq+xpDI2B r/XbOFj9rIxsEA2zMpoWjFUszT6FF/N+QCeaJko= X-Google-Smtp-Source: ABdhPJybaQhCKhanDm+cqkiKnTa6K9p74JWbban/OTc7h/yX/zSIrHV+4PLEXfXosVx9FB946P8+LPg2ZGtKjMmlUws= X-Received: by 2002:a05:6870:6189:b0:e9:172d:8974 with SMTP id a9-20020a056870618900b000e9172d8974mr12439597oah.287.1652168916064; Tue, 10 May 2022 00:48:36 -0700 (PDT) MIME-Version: 1.0 References: <9290b55b6ae2b04e002ca9dadadd1cca09461482.camel@cybertec.at> <763B5AF0-1C9E-4796-9639-F969A2E66189@yandex-team.ru> In-Reply-To: <763B5AF0-1C9E-4796-9639-F969A2E66189@yandex-team.ru> From: Dilip Kumar Date: Tue, 10 May 2022 13:18:20 +0530 Message-ID: Subject: Re: An attempt to avoid locally-committed-but-not-replicated-to-standby-transactions in synchronous replication To: Andrey Borodin Cc: Bharath Rupireddy , 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, May 9, 2022 at 4:39 PM Andrey Borodin wrote: > > On 9 May 2022, at 14:44, Dilip Kumar wrote: > > > > IMHO, making it wait for some amount of time, based on GUC is not a > > complete solution. It is just a hack to avoid the problem in some > > cases. > > Disallowing cancelation of locally committed transactions is not a hack. It's removing of a hack that was erroneously installed to make backend responsible to Ctrl+C (or client side statement timeout). I might be missing something but based on my understanding the approach is not disallowing the query cancellation but it is just adding the configuration for how much to delay before canceling the query. That's the reason I mentioned that this is not a guarenteed solution. I mean with this configuration value also you can not avoid problems in all the cases, right? -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com