Horton

Re: Add Information during standby recovery conflicts

Kyotaro Horiguchi <horikyota.ntt@gmail.com>

View thread View on postgr.es
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: masao.fujii@oss.nttdata.com
Cc: bdrouvot@amazon.com, sawada.mshk@gmail.com, alvherre@alvh.no-ip.org, masahiko.sawada@2ndquadrant.com, pgsql-hackers@postgresql.org
Date: 2021-01-08T02:17:12Z
Lists: pgsql-hackers 
At Fri, 8 Jan 2021 01:32:11 +0900, Fujii Masao <masao.fujii@oss.nttdata.com> wrote in 
> 
> Attached is the updated version of the patch. This can be applied to
> current master.
> 
> With the patch, for example, if the startup process waited longer than
> deadlock_timeout for the recovery conflict on the lock, the latter log
> message in the followings would be additionally output.
> 
>     LOG: recovery still waiting after 1001.223 ms: recovery conflict on
>     lock
>     LOG: recovery finished waiting after 19004.694 ms: recovery conflict
>     on lock

+			/*
+			 * Emit the log message if recovery conflict on buffer pin was resolved but
+			 * the startup process waited longer than deadlock_timeout for it.

The first line is beyond the 80th column.

LGTM other than the above.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

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