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 1nTaTL-0002Ed-T3 for pgsql-hackers@arkaria.postgresql.org; Mon, 14 Mar 2022 02:30:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nTaTK-00079M-8I for pgsql-hackers@arkaria.postgresql.org; Mon, 14 Mar 2022 02:30:10 +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 1nTaTJ-00079D-VN for pgsql-hackers@lists.postgresql.org; Mon, 14 Mar 2022 02:30:09 +0000 Received: from mail-pl1-x635.google.com ([2607:f8b0:4864:20::635]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nTaTI-0007bc-2V for pgsql-hackers@lists.postgresql.org; Mon, 14 Mar 2022 02:30:09 +0000 Received: by mail-pl1-x635.google.com with SMTP id n18so9654279plg.5 for ; Sun, 13 Mar 2022 19:30:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:message-id:to:cc:subject:from:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=h2sJIy3oq2UMGzGSvvl6N8LaN0COABJzFQXZuuWO5Z8=; b=ARhwe63MmCKy/ZzLv3TE5MUZq1TKjpEMV4+sxhZhYX9fbFtANrFukoWa7g5phjkvpJ mPjNTFA5jpzkhbzVFU+1oYseY982mlHUpWeXAxNFCequnKYptVgt5IFUAI2d8G6WEPtc GdpK9/moUkuG3jFXX4vUx74R0Xu//WDGDbPcrgiHCzJxSt4cp1Fsq4JtVvXyEW2Z2mDs LBAF7orzrBmSnQhcP0v/tbG4uezjCfYtG9OPNGF9FnJSr3TAtN9vUQdDR84lHbUZb0Rn UuEacjdFa7rArOS2FfMCcKfOAYqt5gCc9WUiKo6d9qm153+9y7WFx3uCljmM9dclkAQI JuFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:message-id:to:cc:subject:from:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=h2sJIy3oq2UMGzGSvvl6N8LaN0COABJzFQXZuuWO5Z8=; b=VlwyRlhkRnt53tSmLn91w7aK+Xe19Ack+eo18zY75n5KeFjEdfjPQRoLth8obZsymH JLpYGdskoKoERGMLie+Zaz0+fsRKxszuyB22xA9dUqdrgu2Bpp04G+WiRlc/Qhq3fnUZ xR7KCf5yDk4ICNCK0Q9ljnViWwwZOwcQJDjoxXiLqkReAJMbf51x/Chw/0m1lg1OkpB0 lWr9vvpxhO+6zj+j/F2z2QWZ/ce0LjoQXmBDYS8UNr05n6NIUoKWfvai9s2FfBbLD6RO cGpT8Isz55jRas29xXqQckeKVqMYbT0TEl1wcGxOmb7ugTH7lK0AlFsQhSkRhyeMZdx4 h9ig== X-Gm-Message-State: AOAM531p/wMJCdMsyIhe+UXEq38zTVfjz/O850LvYOnWO0G8+9Num0mp c8EinHd130ntsFng/K8bgmY= X-Google-Smtp-Source: ABdhPJw1666Q+0nwfBquzq0PGCSVwVfgVpVo+9/RZo0dXI4nv/fOl7BFmPxieOFAG8TrpuKVADBkOg== X-Received: by 2002:a17:90a:a594:b0:1bc:5def:a652 with SMTP id b20-20020a17090aa59400b001bc5defa652mr22929879pjq.167.1647225006408; Sun, 13 Mar 2022 19:30:06 -0700 (PDT) Received: from localhost (KD036014041111.ppp-bb.dion.ne.jp. [36.14.41.111]) by smtp.gmail.com with ESMTPSA id v23-20020a17090a521700b001bbfc181c93sm18637852pjh.19.2022.03.13.19.30.03 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Sun, 13 Mar 2022 19:30:04 -0700 (PDT) Date: Mon, 14 Mar 2022 11:30:02 +0900 (JST) Message-Id: <20220314.113002.1607014104756351937.horikyota.ntt@gmail.com> To: nathandbossart@gmail.com Cc: andres@anarazel.de, bharath.rupireddyforpostgres@gmail.com, satyanarlapuram@gmail.com, pgsql-hackers@lists.postgresql.org Subject: Re: Allow async standbys wait for sync replication From: Kyotaro Horiguchi In-Reply-To: <20220312223332.GA921069@nathanxps13> References: <20220309020123.sneaoijlg3rszvst@alap3.anarazel.de> <20220312223332.GA921069@nathanxps13> User-Agent: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk At Sat, 12 Mar 2022 14:33:32 -0800, Nathan Bossart wrote in > 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. That is, (as my understanding) async standbys are required to allow overwriting existing unreplayed records after reconnection. But, putting aside how to remember that LSN, if that happens at a segment boundary, the async replica may run into the similar situation with the missing-contrecord case. But standby cannot insert any original record to get out from that situation. regards. -- Kyotaro Horiguchi NTT Open Source Software Center