Horton

Re: Add Information during standby recovery conflicts

Drouvot, Bertrand <bdrouvot@amazon.com>

View thread View on postgr.es
From: "Drouvot, Bertrand" <bdrouvot@amazon.com>
To: Fujii Masao <masao.fujii@oss.nttdata.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: <sawada.mshk@gmail.com>, <alvherre@alvh.no-ip.org>, <masahiko.sawada@2ndquadrant.com>, <pgsql-hackers@postgresql.org>
Date: 2021-01-08T05:15:26Z
Lists: pgsql-hackers 
Hi,

On 1/8/21 5:19 AM, Fujii Masao wrote:
>
> 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.

The patch looks good to me.

Bertrand

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