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 1mLJJn-0001pS-O0 for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Sep 2021 06:01:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mLJJl-0008KH-U0 for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Sep 2021 06:01:49 +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 1mLJJl-0008K9-MK for pgsql-hackers@lists.postgresql.org; Wed, 01 Sep 2021 06:01:49 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mLJJj-0006Kl-I7 for pgsql-hackers@lists.postgresql.org; Wed, 01 Sep 2021 06:01:49 +0000 Received: from hrk.local (p2388012-ipbf1027funabasi.chiba.ocn.ne.jp [118.6.6.12]) by oss.nttdata.com (Postfix) with ESMTPSA id E9B4D605FC; Wed, 1 Sep 2021 15:01:43 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.3 at oss.nttdata.com Subject: Re: prevent immature WAL streaming To: Andres Freund Cc: Alvaro Herrera , Pg Hackers , "Bossart, Nathan" , Kyotaro Horiguchi , =?UTF-8?B?6JSh5qKm5aifKOeOiuS6jik=?= , Jakub Wartak References: <20210831042949.52eqp5xwbxgrfank@alap3.anarazel.de> <202108311356.sl33wcpcz5x6@alvherre.pgsql> <20210831155333.2vv2zdf7v4nhh2m2@alap3.anarazel.de> <20210901031524.mdo6aayalmd5jxly@alap3.anarazel.de> From: Fujii Masao Message-ID: <8acc33c8-fb75-fda4-8909-50d21f9e8725@oss.nttdata.com> Date: Wed, 1 Sep 2021 15:01:43 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <20210901031524.mdo6aayalmd5jxly@alap3.anarazel.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2021/09/01 12:15, Andres Freund wrote: > Hi, > > On 2021-09-01 11:34:34 +0900, Fujii Masao wrote: >> On 2021/09/01 0:53, Andres Freund wrote: >>> Of course, we need to be careful to not weaken WAL validity checking too >>> much. How about the following: >>> >>> If we're "aborting" a continued record, we set XLP_FIRST_IS_ABORTED_PARTIAL on >>> the page at which we do so (i.e. the page after the valid end of the WAL). >> >> When do you expect that XLP_FIRST_IS_ABORTED_PARTIAL is set? It's set >> when recovery finds a a partially-flushed segment-spanning record? >> But maybe we cannot do that (i.e., cannot overwrite the page) because >> the page that the flag is set in might have already been archived. No? > > I was imagining that XLP_FIRST_IS_ABORTED_PARTIAL would be set in the "tail > end" of a partial record. I.e. if there's a partial record starting in the > successfully archived segment A, but the end of the record, in B, has not been > written to disk before a crash, we'd set XLP_FIRST_IS_ABORTED_PARTIAL at the > end of the valid data in B. Which could not have been archived yet, or we'd > not have a partial record. So we should never need to set the flag on an > already archived page. Thanks for clarifying that! Unless I misunderstand that, when recovery ends at a partially-flushed segment-spanning record, it sets XLP_FIRST_IS_ABORTED_PARTIAL in the next segment before starting writing new WAL data there. Therefore XLP_FIRST_IS_CONTRECORD or XLP_FIRST_IS_ABORTED_PARTIAL must be set in the next segment following a partially-flushed segment-spanning record. If none of them is set, the validation code in recovery should report an error. Yes, this design looks good to me. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION