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 1pfdq6-0008MS-6o for pgsql-hackers@arkaria.postgresql.org; Fri, 24 Mar 2023 09:36:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pfdq5-0004mS-0r for pgsql-hackers@arkaria.postgresql.org; Fri, 24 Mar 2023 09:36:01 +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 1pfdq4-0004mI-NU for pgsql-hackers@lists.postgresql.org; Fri, 24 Mar 2023 09:36:00 +0000 Received: from out5-smtp.messagingengine.com ([66.111.4.29]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pfdpx-0007fo-Bd for pgsql-hackers@lists.postgresql.org; Fri, 24 Mar 2023 09:36:00 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 23C115C00AE; Fri, 24 Mar 2023 05:35:51 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Fri, 24 Mar 2023 05:35:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1679650551; x= 1679736951; bh=5AaDKuLzlrdxb15wwEuHUOJF0nrgmk4oyf55r/VQE8A=; b=Y rgTevhQSqorw00cRFG95VsWKt/CDauWs6HxPgKnvkzCh16+DQdFGcW/U2rNmR8sb z4kzMPFXAjG2tnxvLUDh/GLJyFTwvP/VoQqm89XV0d+/sx+qb+zNruVw79j2b3Qy Iwlk2toC7L7xF5MIk2cN5EnKBxW8A0mSUMxvSDOyLy5VXtLQKO5kROMSE9ZReVzF fg+3YJP+6DZla8dN4/hong/nfvpzyMVG8z/zuA+6boblMoeLZNd4t0oug42uugDK NXxnhi5kWCbPimXoZGOmrcEXDtq2GQ2IoGeGNq+AOmhUqVh0SVahLThaAlgx+F4k ISBzFcc3CrXZL3sxLlARA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdegiedgtdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkgggtugfgjgesthekredttddtjeenucfhrhhomheptehlvhgr rhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh eqnecuggftrfgrthhtvghrnhepvdektdffudfftdffffehfffhjeejhffgieeuueekjeek fffgudffhfduffffueevnecuffhomhgrihhnpegvnhhtvghrphhrihhsvggusgdrtghomh enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhv hhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 24 Mar 2023 05:35:50 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id EE1C5386; Fri, 24 Mar 2023 10:35:47 +0100 (CET) Date: Fri, 24 Mar 2023 10:35:47 +0100 From: Alvaro Herrera To: Greg Stark Cc: Bharath Rupireddy , Euler Taveira , Amit Kapila , Kyotaro Horiguchi , PostgreSQL Hackers Subject: Re: add log messages when replication slots become active and inactive (was Re: Is it worth adding ReplicationSlot active_pid to ReplicationSlotPersistentData?) Message-ID: <20230324093547.amsbfoql2kmbqco2@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2023-Mar-23, Greg Stark wrote: > On Thu, 23 Mar 2023 at 23:30, Bharath Rupireddy > wrote: > > > > > + ereport(log_replication_commands ? LOG : DEBUG3, > > > + (errmsg("acquired physical replication slot \"%s\"", > > > + slotname))); > > So this is just a bit of bike-shedding but I don't feel like these log > messages really meet the standard we set for our logging. Like what > did the acquiring? What does "acquired" actually mean for a > replication slot? Is there not any meta information about the > acquisition that can give more context to the reader to make this > message more meaningful? > > I would expect a log message like this to say, I dunno, something like > "physical replication slot \"%s\" acquired by streaming TCP connection > to 192.168.0.1:999 at LSN ... with xxxMB of logs to read" Hmm, I don't disagree with your argument in principle, but I think this proposal is going too far. I think stating the PID is more than sufficient. And I don't think we need this patch to go great lengths to explain what acquisition is, either; I mean, maybe that's a good thing to have, but then that's a different patch. > I even would be wondering if the other end shouldn't also be logging a > corresponding log and we shouldn't be going out of our way to ensure > there's enough information to match them up and presenting them in a > way that makes that easy. Hmm, you should be able to match things using the connection information. I don't think the slot acquisition operation in itself is that important. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "Use it up, wear it out, make it do, or do without"