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 1kidzx-0000EA-TV for pgsql-hackers@arkaria.postgresql.org; Fri, 27 Nov 2020 13:41:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kidzw-0001TL-Mp for pgsql-hackers@arkaria.postgresql.org; Fri, 27 Nov 2020 13:41:16 +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 1kidzv-0001T8-LY for pgsql-hackers@lists.postgresql.org; Fri, 27 Nov 2020 13:41:16 +0000 Received: from [64.147.123.24] (helo=wout1-smtp.messagingengine.com) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kidzt-0002gr-9g for pgsql-hackers@postgresql.org; Fri, 27 Nov 2020 13:41:14 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 1FA5EE1E; Fri, 27 Nov 2020 08:41:01 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Fri, 27 Nov 2020 08:41:01 -0500 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:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=sPII7UIvAS78/9B64 snT9eRAHbFwOMIs2CPttRoIuew=; b=aM1S3xtusxmRs+fLa9uNXqif2etb2wjn3 +soyQxXxQpD5ktHAPKlorpp4T0GeEuxWrzGRspqJEbUpZoWCRMzvjA0vmcwHkZmZ I/Svuosu6MUq+MnS4AvCf4Eo9sr9Xto5pZKZ2/UBZEp4snq1jKxuVLaQZNIJwlG1 9YejvXd8TSGE5Sclv21elhE+bPn73yAOznxIxbYmPcF5lzIhsFn2f0t3etAwoUSI USScfptQN6EGWOrz451MSrN3vRdlo0Zssf1k4QhgkDZzjbKXo6eFWTbXwoFGqKlC GFZXSHlkdz4a7RjL5XxFG7bg54Cc35QEL3PIrjRuA214IT289zTGw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudehgedgheehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggujggfsehttdertddtredvnecuhfhrohhmpeetlhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpeevgfelveegueejgefhgeetgefhgeehieefheehleetteei udeiiefhgffgheffteenucfkphepudeltddrleehrddukedrjeelnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhhvghrrhgvsegrlhhv hhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: from perhan.alvh.no-ip.org (unknown [190.95.18.79]) by mail.messagingengine.com (Postfix) with ESMTPA id B9EF13280064; Fri, 27 Nov 2020 08:40:59 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 5A3142A0D0C; Fri, 27 Nov 2020 10:40:57 -0300 (-03) Date: Fri, 27 Nov 2020 10:40:57 -0300 From: Alvaro Herrera To: "Drouvot, Bertrand" Cc: Masahiko Sawada , Fujii Masao , Masahiko Sawada , Kyotaro Horiguchi , PostgreSQL-development Subject: Re: Add Information during standby recovery conflicts Message-ID: <20201127134057.GA15122@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <61a9ad81-9436-dbf2-22a5-044843aa6ba3@amazon.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Host-Lookup-Failed: Reverse DNS lookup failed for 64.147.123.24 (deferred) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020-Nov-27, Drouvot, Bertrand wrote: > + if (nprocs > 0) > + { > + ereport(LOG, > + (errmsg("%s after %ld.%03d ms", > + get_recovery_conflict_desc(reason), msecs, usecs), > + (errdetail_log_plural("Conflicting process: %s.", > + "Conflicting processes: %s.", > + nprocs, buf.data)))); > + } > +/* Return the description of recovery conflict */ > +static const char * > +get_recovery_conflict_desc(ProcSignalReason reason) > +{ > + const char *reasonDesc = gettext_noop("unknown reason"); > + > + switch (reason) > + { > + case PROCSIG_RECOVERY_CONFLICT_BUFFERPIN: > + reasonDesc = gettext_noop("recovery is still waiting for recovery conflict on buffer pin"); > + break; This doesn't work from a translation point of view. First, you're building a sentence from parts, which is against policy. Second, you're not actually invoking gettext to translate the string returned by get_recovery_conflict_desc. I think this needs to be rethought. To handle the first problem I suggest to split the error message in two. One phrase is the complain that recovery is waiting, and the other string is the reason for the wait. Separate both either by splitting with a :, or alternatively put the other sentence in DETAIL. (The latter would require to mix with the list of conflicting processes, which might be hard.) The first idea would look like this: LOG: recovery still waiting after %ld.03d ms: for recovery conflict on buffer pin DETAIL: Conflicting processes: 1, 2, 3. To achieve this, apart from editing the messages returned by get_recovery_conflict_desc, you'd need to ereport this way: ereport(LOG, errmsg("recovery still waiting after %ld.%03d ms: %s", msecs, usecs, _(get_recovery_conflict_desc(reason))), errdetail_log_plural("Conflicting process: %s.", "Conflicting processes: %s.",