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>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2021-01-08T06:24:36Z
Lists: pgsql-hackers 

On 2021/01/08 14:02, Drouvot, Bertrand wrote:
> Hi,
> 
> On 1/7/21 4:51 PM, Fujii Masao wrote:
>> Thanks for the review! I pushed the latest patch.
>>
> Thanks all of you for your precious help on this patch!
> 
> The original idea behind this thread has been split into 3 pieces.
> 
> Pieces 1 (9d0bd95fa90a7243047a74e29f265296a9fc556d) and 2 (0650ff23038bc3eb8d8fd851744db837d921e285) have now been committed, the last one is to add more information regarding the canceled statements (if any), like:
> 
> * What was the blocker(s) doing?

This "canceled statement" is just one that's canceled by recovery conflict?
If so, the blocker is always the startup process? Sorry maybe I fail to
understand this idea well..


> * When did the blocker(s) started their queries (if any)?

If the blocker is the startup process, it doesn't start any query at all?

Anyway if you post the patch, I'm happy to review that!

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