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 1nTAIy-0004vD-RJ for pgsql-hackers@arkaria.postgresql.org; Sat, 12 Mar 2022 22:33:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nTAIx-0001H5-Ek for pgsql-hackers@arkaria.postgresql.org; Sat, 12 Mar 2022 22:33:43 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nTAIx-0001Gw-3n for pgsql-hackers@lists.postgresql.org; Sat, 12 Mar 2022 22:33:43 +0000 Received: from mail-pj1-x102d.google.com ([2607:f8b0:4864:20::102d]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nTAIr-0004iA-AV for pgsql-hackers@lists.postgresql.org; Sat, 12 Mar 2022 22:33:42 +0000 Received: by mail-pj1-x102d.google.com with SMTP id rm8-20020a17090b3ec800b001c55791fdb1so3436825pjb.1 for ; Sat, 12 Mar 2022 14:33:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=iVEMAAgJidE9zzXKnBFO+ZJQWFROWRaqxiHyeqSoirU=; b=hb4TQDi0sEwzlE8sS5Ebx39Z/GcdBynPvF75HMFWF/I3QCi+XUrmmTkTZzHjNmRweW kO8lesATRCeQUU3xF9hrmqQ63G0BkdbTMfL0bNL8A4om+Cl8oq9oVTr4+L1kKtZ3HS+k jfliPk2eDl5Jb8dwjmT/tunZUIB6bSSHavq+tR9QtKYPBdZzlQ5jdudUArBmxTjH9Krc L5LPX7X3BIrtsG0JNH8190tdqlKb72sRarmX/XzQapuU8QOPIUHWOUrELI82DMvjkPml hrO+Ef0rUdvkh6uNHWPI+0p+7MWHDPA54HRev8sly2G+N6F8nQLrQ3rirPbFluQ+mhuV DMfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=iVEMAAgJidE9zzXKnBFO+ZJQWFROWRaqxiHyeqSoirU=; b=pncDdGFMq6/tfsdzLOJgE/Sb3yRrAT2RzmHMzZXc0ztO9bBGMs/KhZLjQrlGMCjnhs DheZgR0B0Bn6x5pxHWUyqkYm9iGbnLnV7RFMg4VGnqoczrVe9/IlEIQRR4MVegTak2BX f06D0cbdFNC4mYqBOqSy5pxykOeKPoLjEv0EDbYL+wS4PDM/SmkTjkAKeGPHSdAwzwmm 3hn2oEUuc0CLIFu6bTwdvd+GEiERN6mPHTnjWIrHthbFeqGu//Fjhx0h8RcrNUnEbkj8 xAW8evHm8fnEE9T8R6MRf5zb735wxox6od4R/Ir27cYUTpAsov0k0/wVck2UfyqnHzj6 PBrA== X-Gm-Message-State: AOAM533m6ot0d0ST6x24hO8fcp61T/P7SD/OeS/ruDlvxGZISQWREV1A Y2WbmhpZ4+Kvx9+tjB9BlQKzHLHU9a4= X-Google-Smtp-Source: ABdhPJwwCyQrknwbF2EWp/rPsKDbFaMdZ0+s+0R/jnbDCxsfhQeYXZSHeQp7STvIyitEYnVtkrF6mg== X-Received: by 2002:a17:902:864b:b0:14c:d45e:a77b with SMTP id y11-20020a170902864b00b0014cd45ea77bmr16885891plt.143.1647124414941; Sat, 12 Mar 2022 14:33:34 -0800 (PST) Received: from nathanxps13 ([50.54.155.70]) by smtp.gmail.com with ESMTPSA id q21-20020a63e215000000b00373efe2cbcbsm12232674pgh.80.2022.03.12.14.33.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 12 Mar 2022 14:33:34 -0800 (PST) Date: Sat, 12 Mar 2022 14:33:32 -0800 From: Nathan Bossart To: Andres Freund Cc: Bharath Rupireddy , Kyotaro Horiguchi , SATYANARAYANA NARLAPURAM , PostgreSQL Hackers Subject: Re: Allow async standbys wait for sync replication Message-ID: <20220312223332.GA921069@nathanxps13> References: <20220301.163431.1826638724406024793.horikyota.ntt@gmail.com> <20220301170537.GA1031413@nathanxps13> <20220301212700.GB1033258@nathanxps13> <20220304195602.GA1184024@nathanxps13> <20220305202752.4oll4hgztlgdfykl@alap3.anarazel.de> <20220309020123.sneaoijlg3rszvst@alap3.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220309020123.sneaoijlg3rszvst@alap3.anarazel.de> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Mar 08, 2022 at 06:01:23PM -0800, Andres Freund wrote: > To me it's architecturally the completely wrong direction. We should move in > the *other* direction, i.e. allow WAL to be sent to standbys before the > primary has finished flushing it locally. Which requires similar > infrastructure to what we're discussing here. I think this is a good point. After all, WALRead() has the following comment: * XXX probably this should be improved to suck data directly from the * WAL buffers when possible. Once you have all the infrastructure for that, holding back WAL replay on async standbys based on synchronous replication might be relatively easy. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com