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 1lOzSi-0001zn-5S for pgsql-bugs@arkaria.postgresql.org; Wed, 24 Mar 2021 09:06:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lOzSB-0003Il-Dv for pgsql-bugs@arkaria.postgresql.org; Wed, 24 Mar 2021 09:05:27 +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 1lOzSA-0003Ie-Pr for pgsql-bugs@lists.postgresql.org; Wed, 24 Mar 2021 09:05:27 +0000 Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lOzS8-0003iw-1E for pgsql-bugs@lists.postgresql.org; Wed, 24 Mar 2021 09:05:25 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 2C4D05C0044; Wed, 24 Mar 2021 05:05:23 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 24 Mar 2021 05:05:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=QB0c3Hm7OKbS0cV4oj3D2urHrRecoXSkOVPB4lHXY04=; b=hqVcHHTj rOD0TPmrrCG+oIOqLDCE1vJlwuUQsyuSyEqBdh2msdcoscdT03Pg/HgUdMcIor2I e2N4caMp8r5VtpIrsFxLyAK+p5LAP4thrd4XnEFNWkSriZPrC9Xp9ynBFqmoAq3X s265J2omlSH0DaZAoHQCHLmzHlC9tsNb0KvzNLOUoGE5gh9doAaEXEFono/13UZK hFR3nCXt3ynj3NUfgqNjhKMw4uwtYA71hCGfGInXH7gwn4+3AFeViVCOZ6hAH3hc etSFNp+flZstXCe7Z5vGDh2+AvFWelCUYhVBZVeJjhUYNvhibJaeZmx857sUhn/G jJQdZZG6UpdvFw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudegjedguddvkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkgggtugfgjggfsehtkeertddtredunecuhfhrohhmpeetlhhv rghrohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorh hgqeenucggtffrrghtthgvrhhnpeeufffhjeeiueeuffegvddukeegledtveeivdeiueef ieeivefgteehueefteehvdenucfkphepudeltddrleehrdduledrleehnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhhvghrrhgvsegr lhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: from perhan.alvh.no-ip.org (unknown [190.95.19.95]) by mail.messagingengine.com (Postfix) with ESMTPA id A2175108005C; Wed, 24 Mar 2021 05:05:21 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 119BE2A0EDC; Wed, 24 Mar 2021 06:05:19 -0300 (-03) Date: Wed, 24 Mar 2021 06:05:19 -0300 From: Alvaro Herrera To: Fujii Masao Cc: zoulx1982@163.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #16931: source code problem about commit_ts Message-ID: <20210324090519.GA14510@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2021-Mar-18, Fujii Masao wrote: > On 2021/03/18 13:36, PG Bug reporting form wrote: > > Hi, > > recently i am reading commit ts code, and i have a problem about it. > > i found commit_ts_redo call TransactionTreeSetCommitTsData with last param > > `write_xlog` true, > > but RecordTransactionCommitPrepared and RecordTransactionCommit call > > TransactionTreeSetCommitTsData > > with `write_xlog` false, which cause there are never xlog with commit_ts - > > COMMIT_TS_SETTS type. Hmm, sharp eyes. > I guess that TransactionTreeSetCommitTsData(write_xlog=true) is basically > used by some extensions using commit_ts. I am not aware of any extensions that do that. > IIUC commit_ts_redo() is called during recovery. So it's strange that > commit_ts_redo() calls TransactionTreeSetCommitTsData() with write_xlog=true > because no new WAL can be generated during recovery. Probably this is a bug, > and it should be called with write_xlog=false, instead. Patch attached. Yeah, it seems like a bug. With your patch, the write_xlog=true path becomes unused, and thus the whole COMMIT_TS_SETTS record, so we could remove those things in branch master. The timestamp is acquired from the COMMIT record. > Also one problem is that there is no test for WAL replay of COMMIT_TS_SETTS > for now. Maybe this is why we could not find that bug. Yeah, coverage for xlog in commit_ts.c is lacking. -- Álvaro Herrera 39°49'30"S 73°17'W "En las profundidades de nuestro inconsciente hay una obsesiva necesidad de un universo lógico y coherente. Pero el universo real se halla siempre un paso más allá de la lógica" (Irulan)