Horton

Re: Add Information during standby recovery conflicts

Fujii Masao <masao.fujii@oss.nttdata.com>

View thread View on postgr.es
From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.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-08T04:19:18Z
Lists: pgsql-hackers

Attachments


On 2021/01/08 11:17, Kyotaro Horiguchi wrote:
> 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.

Thanks for pointing out this! This happened because I forgot to run pgindent
for bufmgr.c. Attached is the updated version of the patch.

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

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