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 1pfSgh-00021B-TB for pgsql-hackers@arkaria.postgresql.org; Thu, 23 Mar 2023 21:41:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pfSgg-00088c-PW for pgsql-hackers@arkaria.postgresql.org; Thu, 23 Mar 2023 21:41:34 +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 1pfSge-00088R-VC for pgsql-hackers@lists.postgresql.org; Thu, 23 Mar 2023 21:41:34 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pfSgX-0003hJ-Fe for pgsql-hackers@lists.postgresql.org; Thu, 23 Mar 2023 21:41:31 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 70DFA5C0164; Thu, 23 Mar 2023 17:41:23 -0400 (EDT) Received: from imap49 ([10.202.2.99]) by compute6.internal (MEProxy); Thu, 23 Mar 2023 17:41:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eulerto.com; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm1; t=1679607683; x=1679694083; bh=p9 Tv9B6pXt46XX/2zPWltMm5ijGLQF0fqvh0NWxySVs=; b=CUyfL4xW+FVCp5Uhfu tshTLYDxnrbT8T9mqNbrsF/vx/SL+1P/N2YSw5GcJDJoSOwMZhCQuy7PCcVKxma2 Em5hO8eJD+SW4y5K/3x3Ses7HArv2lXx3dvTsVhJaUe3T3qTp4zILkmawZoHOEje 9vofqpVPrtpPy6V8kdk2/3xRTbYBkdOFuGPyjO7bozg8sOJ83yQKTGWpvV+MZe1q DDO6qowCDcv6E6mz2BI+ED9qBdcerYpzTwlNiMKDzGJd+cYmhyfhcs8hhEksOVFO vX+AfKHPgIrpinYaWeuyUD4ZiLNQ8buDnl4pq+XSvU8PKxsNUmuSL2aKEs/j5Tkd L15w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references: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=1679607683; x=1679694083; bh=p9Tv9B6pXt46X X/2zPWltMm5ijGLQF0fqvh0NWxySVs=; b=agvU1WAKniVrnLZz8SY9HgoFd7WqS a6I0nK3vkNhm9OenQZ0WTGrJavLpRY5RqcZJ51NC7foB1FQiNzURuwdfNd01eA3N 3mBUb2KYDuTT3egsqQ1DlCGqQUVFJIM4aYk3yAdmn6HGoy+fZ4FSq+vFSd3Rsbj4 Njmlg0d/2laTNICQeoZAj5EgJmtyniuVCIaRzd8e3eEhfJBPmG6CnhLAZyqfNAvE 7i+YP/WG9rNeNgKJkSp4hpvSgnG42kwwILpa+PgawOb2vc+0Kfl0dITSvXyInYwr FfcdTtfDuJa7hF2EGGF9pReij7a8Ef8Iw1WxnpIO4Zc7sW/NVTA14yvbA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdeggedgudehvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvvefutgesrgdtreerreerjeenucfhrhhomhepfdfg uhhlvghrucfvrghvvghirhgrfdcuoegvuhhlvghrsegvuhhlvghrthhordgtohhmqeenuc ggtffrrghtthgvrhhnpeegueegleehfeehgeevgffghffggfetueduvedvkeehvddvkefg heekieetvdegvdenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtohhmnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvghulhgvrhes vghulhgvrhhtohdrtghomh X-ME-Proxy: Feedback-ID: i0c21471d:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2EBFB15A008E; Thu, 23 Mar 2023 17:41:23 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-236-g06c0f70e43-fm-20230313.001-g06c0f70e Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20230323100726.vzrgvpjt3il7uemq@alvherre.pgsql> Date: Thu, 23 Mar 2023 18:40:26 -0300 From: "Euler Taveira" To: "Bharath Rupireddy" , "Alvaro Herrera" Cc: "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?) Content-Type: multipart/alternative; boundary=f21ffa602bcc4ef2ae83cc8286ab1b18 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --f21ffa602bcc4ef2ae83cc8286ab1b18 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 23, 2023, at 2:33 PM, Bharath Rupireddy wrote: > On Thu, Mar 23, 2023 at 3:37=E2=80=AFPM Alvaro Herrera wrote: > > > > On 2023-Mar-22, Amit Kapila wrote: > > > > > I see that you have modified the patch to address the comments from > > > Alvaro. Personally, I feel it would be better to add such a messag= e at > > > a centralized location instead of spreading these in different cal= lers > > > of slot acquire/release functionality to avoid getting these misse= d in > > > the new callers in the future. However, if Alvaro and others think > > > that the current style is better then we should go ahead and do it > > > that way. I hope that we should be able to decide on this and get = it > > > into PG16. Anyone else would like to weigh in here? > > > > I like Peter Smith's suggestion downthread. >=20 > +1. Please review the attached v8 patch further. If you are adding separate functions as suggested, you should add a comm= ent at the top of ReplicationSlotAcquire() and ReplicationSlotRelease() functio= ns saying that LogReplicationSlotAquired() and LogReplicationSlotReleased() functions should be called respectively after it. My suggestion is that the functions should have the same name with a "Lo= g" prefix. On of them has a typo "Aquired" in its name. Hence, LogReplicationSlotAcquire() and LogReplicationSlotRelease() as names. It= is easier to find if someone is grepping by the origin function. I prefer a sentence that includes a verb. physical replication slot \"%s\" is acquired logical replication slot \"%s\" is released Isn't the PID important for this use case? If so, of course, you can rel= y on log_line_prefix (%p) but if the PID is crucial for an investigation then= it should also be included in the message. -- Euler Taveira EDB https://www.enterprisedb.com/ --f21ffa602bcc4ef2ae83cc8286ab1b18 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 23,= 2023, at 2:33 PM, Bharath Rupireddy wrote:
On Thu, Mar 23, 2023 at 3:37=E2=80=AFPM= Alvaro Herrera <alvherre@= alvh.no-ip.org> wrote:
>
> On 2= 023-Mar-22, Amit Kapila wrote:
>
> >= ; I see that you have modified the patch to address the comments from
> > Alvaro. Personally, I feel it would be better to a= dd such a message at
> > a centralized location inst= ead of spreading these in different callers
> > of s= lot acquire/release functionality to avoid getting these missed in
> > the new callers in the future. However, if Alvaro and= others think
> > that the current style is better t= hen we should go ahead and do it
> > that way. I hop= e that we should be able to decide on this and get it
>= > into PG16. Anyone else would like to weigh in here?
= >
> I like Peter Smith's suggestion downthread.
<= /div>

+1. Please review the attached v8 patch further= .
If you are adding separate functions as sug= gested, you should add a comment at
the top of Replication= SlotAcquire() and ReplicationSlotRelease() functions
sayin= g that LogReplicationSlotAquired() and LogReplicationSlotReleased()
<= /div>
functions should be called  respectively after it.

My suggestion is that the functions should have t= he same name with a "Log"
prefix. On of them has a typo "A= quired" in its name. Hence,
LogReplicationSlotAcquire() an= d LogReplicationSlotRelease() as names. It is
easier to fi= nd if someone is grepping by the origin function.

I prefer a sentence that includes a verb.

  physical replication slot \"%s\" is acquired
=   logical replication slot \"%s\" is released

Isn't the PID important for this use case? If so, of course, you= can rely on
log_line_prefix (%p) but if the PID is crucia= l for an investigation then it
should also be included in = the message.


--
Euler= Taveira
=

--f21ffa602bcc4ef2ae83cc8286ab1b18--