Re: Add Information during standby recovery conflicts

Drouvot, Bertrand <bdrouvot@amazon.com>

From: "Drouvot, Bertrand" <bdrouvot@amazon.com>
To: Fujii Masao <masao.fujii@oss.nttdata.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:42:46Z
Lists: pgsql-hackers
On 1/8/21 7:24 AM, Fujii Masao wrote:
> CAUTION: This email originated from outside of the organization. Do 
> not click links or open attachments unless you can confirm the sender 
> and know the content is safe.
>
>
>
> 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..
>
>
By blocker, I meant the one being canceled (I had in mind the startup 
process being the blocked one, not the blocker one). Sorry if i have not 
been clear enough.

As an example, it could provide things like:

2020-06-15 06:48:54.778 UTC [7037] LOG: about to interrupt pid: 7037, 
backend_type: client backend, state: active, wait_event_type: Timeout, 
wait_event: PgSleep, query_start: 2020-06-15 06:48:13.008427+00
2020-06-15 06:48:54.778 UTC [7037] ERROR: canceling statement due to 
conflict with recovery

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

Thanks!

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