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 1kjSC3-0001OU-Ay for pgsql-hackers@arkaria.postgresql.org; Sun, 29 Nov 2020 19:17: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 1kjSC2-0006PB-Ak for pgsql-hackers@arkaria.postgresql.org; Sun, 29 Nov 2020 19:17:06 +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 1kjSC2-0006P4-3s for pgsql-hackers@lists.postgresql.org; Sun, 29 Nov 2020 19:17:06 +0000 Received: from mail.postgrespro.ru ([93.174.131.139]) by magus.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kjSBv-0001pp-KK for pgsql-hackers@postgresql.org; Sun, 29 Nov 2020 19:17:05 +0000 Received: from [192.168.1.70] (ppp91-79-61-252.pppoe.mtu-net.ru [91.79.61.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.postgrespro.ru (Postfix) with ESMTPSA id BD8F821C3353; Sun, 29 Nov 2020 22:16:58 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1606677419; bh=7ltvYRIjIvRTyrB4r5JfIoGH0wdnTszCW9aFc37TY+Y=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=aXC+U7/RhTR/Bck3IBiK49Q8aVhO+Vbvghn7pBiYVz9aXbmta+m8IwucGRIPeWm7v W1SwipjyZxt8u00OZH6KrlV3GWUx70G1ns2dbd70I/zVEYv/H4kFImW4al7rDe+54X 8V09K3Fdon9YXcvWL5Kktoh3HrWytAA2rAqEd5Ok= Subject: Re: archive status ".ready" files may be created too early To: Kyotaro Horiguchi , hlinnaka@iki.fi Cc: matsumura.ryo@fujitsu.com, bossartn@amazon.com, masao.fujii@gmail.com, pgsql-hackers@postgresql.org References: <20200706.141340.695077532820840879.horikyota.ntt@gmail.com> <65e309c0-5d51-7f9e-80ed-947414db8280@iki.fi> <20201014.090628.839639906081252194.horikyota.ntt@gmail.com> From: Anastasia Lubennikova Message-ID: <6009933f-5b21-db6a-a23a-14a414aba94d@postgrespro.ru> Date: Sun, 29 Nov 2020 22:16:58 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20201014.090628.839639906081252194.horikyota.ntt@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 14.10.2020 03:06, Kyotaro Horiguchi wrote: > The patch includes a fix for primary->standby case. But I'm not sure > we can do that in the cascaded case. A standby is not aware of the > structure of a WAL blob and has no idea of up-to-where to send the > received blobs. However, if we can rely on the behavior of CopyData > that we always receive a blob as a whole sent from the sender at once, > the cascaded standbys are free from the trouble (as far as the > cascaded-standby doesn't crash just before writing the last-half of a > record into pg_wal and after archiving the last full-segment, which > seems unlikely.). > > regards. > Status update for a commitfest entry. This entry was "Waiting on author" during this CF. As I see, the latest message contains new version of the patch. Does it need more work? Are you going to continue working on it? -- Anastasia Lubennikova Postgres Professional: http://www.postgrespro.com The Russian Postgres Company