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: "Drouvot, Bertrand" <bdrouvot@amazon.com>, Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-11-30T17:59:15Z
Lists: pgsql-hackers 

On 2020/11/20 18:17, Drouvot, Bertrand wrote:
> Hi,
> 
> On 11/17/20 4:44 PM, Fujii Masao wrote:
>>
>> Thanks for updating the patch! Here are review comments.
>>
>> +        Controls whether a log message is produced when the startup process
>> +        is waiting longer than <varname>deadlock_timeout</varname>
>> +        for recovery conflicts.
>>
>> But a log message can be produced also when the backend is waiting
>> for recovery conflict. Right? If yes, this description needs to be corrected.
> 
> Thanks for looking at it!
> 
> I don't think so, only the startup process should write those new log messages.
> 
> What makes you think that would not be the case?

Probably my mis-underding of the patch did that. Sorry for noise..

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