Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ieT2K-0000hU-7H for pgsql-hackers@arkaria.postgresql.org; Tue, 10 Dec 2019 00:05:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ieT1J-0007uL-L2 for pgsql-hackers@arkaria.postgresql.org; Tue, 10 Dec 2019 00:04:53 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ieT1H-0007uE-Jk for pgsql-hackers@lists.postgresql.org; Tue, 10 Dec 2019 00:04:53 +0000 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ieT1C-0000Cu-Hn for pgsql-hackers@postgresql.org; Tue, 10 Dec 2019 00:04:51 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id AB39487A; Mon, 9 Dec 2019 19:04:42 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Mon, 09 Dec 2019 19:04:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=3CMTw/HqFacxlaIAvobeuiAGBIR JSyvd0Zl7EyOYlCI=; b=hxEuz16AwPkQ+ko8oTR06Mj4MJFKHfmVUQokJUSQ+d1 aiXcb9zhzaQd5CAdrhWOW+fkC/1E1I7RkCw0vi2HTSs98UUPKXQUsis0bjo055cs LeQcWx/0SoJ8Ds1gb90gTQ6vzXHKhXIiirtvT9XUvCtxd78nA3sIm21tFOnTVm66 ypi/e+9Xh3Gm49+p593y0GRV5xhfqElfgBPqINqAh7tbzx+WVU++owL3V4hI5A2u WMqldNRr6MJHb/s6rY7hZnkwjZRo5Xc5jPT3LG3tFvqvQ6FfWeqzH68zFvgqHsQq xS8W4qExxcgvIcLRJGXavWRdV6SC+Ib+FVsvuCDwo2A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=3CMTw/ HqFacxlaIAvobeuiAGBIRJSyvd0Zl7EyOYlCI=; b=oXaDWW0HqpCrevzXasgHNL rFdADddhOHHJSh+VopaZ5XfWb97gFGyh8s3JyQ8qolsyIDZMMuBHpKe8NOUCmpcV vtcKqAi5XftkwdnAy3b4Wx8pFdJDrDuXvPZICV09mig4XS88yVO8exw5ruXAEEfD rgqibWmzAXSKKViGcJBEbRIU/cVIhMJsQJIpZWVNIwfKTcJf1cTF+ah8r+77n9it Dr1GFDjSxR+q7bAEMrJoGZ1vqQm3xsACCv0gKIMsU6TA9G2X/Q3X0mclScB0PZ9u J+ZvJdxC6PWnkr2ujQNDSsKntp6mRBQIYU0vdBcIM3VK7Rj820JERw369sURGKTg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudelvddgudefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpeetnhgurhgv shcuhfhrvghunhguuceorghnughrvghssegrnhgrrhgriigvlhdruggvqeenucffohhmrg hinhepvdhnughquhgrughrrghnthdrtghomhenucfkphepudeijedrvddvtddrvdejrddu jeejnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrnhgurhgvshesrghnrghrrgiivghlrd guvgenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from intern.anarazel.de (unknown [167.220.27.177]) by mail.messagingengine.com (Postfix) with ESMTPA id BF3C830600DC; Mon, 9 Dec 2019 19:04:41 -0500 (EST) Date: Mon, 9 Dec 2019 16:04:40 -0800 From: Andres Freund To: Tomas Vondra Cc: pgsql-hackers@postgresql.org Subject: Re: xact_start for walsender & logical decoding not updated Message-ID: <20191210000440.daqpb6nvk3dpcblr@alap3.anarazel.de> References: <20191209234409.exe7osmyalwkt5j4@development> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191209234409.exe7osmyalwkt5j4@development> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, On 2019-12-10 00:44:09 +0100, Tomas Vondra wrote: > I think there's a minor bug in pg_stat_activity tracking of walsender > processes. The issue is that xact_start is only updated at the very > beginning when the walsender starts (so it's almost exactly equal to > backend_start) and then just flips between NULL and that value. > > Reproducing this is trivial - just create a publication/subscription > with the built-in logical replication, and run arbitrary workload. > You'll see that the xact_start value never changes. > > I think the right fix is calling SetCurrentStatementStartTimestamp() > right before StartTransactionCommand() in ReorderBufferCommit, per the > attached patch. > -- > Tomas Vondra http://www.2ndQuadrant.com > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services > diff --git a/src/backend/replication/logical/reorderbuffer.c b/src/backend/replication/logical/reorderbuffer.c > index 53affeb877..5235fb31b8 100644 > --- a/src/backend/replication/logical/reorderbuffer.c > +++ b/src/backend/replication/logical/reorderbuffer.c > @@ -1554,7 +1554,10 @@ ReorderBufferCommit(ReorderBuffer *rb, TransactionId xid, > if (using_subtxn) > BeginInternalSubTransaction("replay"); > else > + { > + SetCurrentStatementStartTimestamp(); > StartTransactionCommand(); > + } I'm quite doubtful this is useful. To me this seems to do nothing but add the overhead of timestamp computation - which isn't always that cheap. I don't think you really can draw meaning from this? Greetings, Andres Freund