Horton

Re: Add Information during standby recovery conflicts

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread View on postgr.es
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>
Date: 2020-11-30T18:25:28Z
Lists: pgsql-hackers 
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.)

Commits

  1. Log long wait time on recovery conflict when it's resolved.

  2. Add GUC to log long wait times on recovery conflicts.

  3. Detect the deadlocks between backends and the startup process.

  4. Get rid of the dedicated latch for signaling the startup process.

  5. Add block information in error context of WAL REDO apply loop