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 1m2xtS-0006ew-Vk for pgsql-bugs@arkaria.postgresql.org; Mon, 12 Jul 2021 15:30:50 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m2xtR-0001Gd-Jh for pgsql-bugs@arkaria.postgresql.org; Mon, 12 Jul 2021 15:30:49 +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 1m2xtR-0001DP-8b for pgsql-bugs@lists.postgresql.org; Mon, 12 Jul 2021 15:30:49 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m2xtP-0000VR-3g for pgsql-bugs@lists.postgresql.org; Mon, 12 Jul 2021 15:30:48 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 16CFUeqK2950682; Mon, 12 Jul 2021 11:30:41 -0400 From: Tom Lane To: John Naylor cc: Japin Li , =?UTF-8?Q?L=C3=A6titia_Avrot?= , pgsql-bugs@lists.postgresql.org Subject: Re: Statistics updates is delayed when using `commit and chain` In-reply-to: References: Comments: In-reply-to John Naylor message dated "Mon, 12 Jul 2021 10:08:42 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2950680.1626103840.1@sss.pgh.pa.us> Date: Mon, 12 Jul 2021 11:30:40 -0400 Message-ID: <2950681.1626103840@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk John Naylor writes: > I understand this functionality to be tracking what happens at the physical > level, in which case it is correct. In any case, the bug reported is clear > and changing that behavior is the focus here. About the patch: I do not think this is a bug at all. The behavior is, and always has been, that we report stats when we are about to wait for client input and are not inside a transaction. Likewise for NOTIFY. The proposed patch randomly changes that in a way that is very likely to break clients. Maybe you can persuade me that there's a reason to move the responsibility for stats reporting to some other place, but please keep your hands OFF of NOTIFY. You clearly haven't the faintest idea what the client contract for that is. regards, tom lane