Date: Mon, 30 Nov 2020 15:25:28 -0300
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>,
	"Drouvot, Bertrand" <bdrouvot@amazon.com>,
	Masahiko Sawada <masahiko.sawada@2ndquadrant.com>,
	Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Add Information during standby recovery conflicts
Message-ID: <20201130182528.GA1854@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <fafa607c-9e85-b742-ab46-2ee807ab9364@oss.nttdata.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On 2020-Dec-01, Fujii Masao wrote:

> +			if (proc)
> +			{
> +				if (nprocs == 0)
> +					appendStringInfo(&buf, "%d", proc->pid);
> +				else
> +					appendStringInfo(&buf, ", %d", proc->pid);
> +
> +				nprocs++;
> 
> What happens if all the backends in wait_list have gone? In other words,
> how should we handle the case where nprocs == 0 (i.e., nprocs has not been
> incrmented at all)? This would very rarely happen, but can happen.
> In this case, since buf.data is empty, at least there seems no need to log
> the list of conflicting processes in detail message.

Yes, I noticed this too; this can be simplified by changing the
condition in the ereport() call to be "nprocs > 0" (rather than
wait_list being null), otherwise not print the errdetail.  (You could
test buf.data or buf.len instead, but that seems uglier to me.)