Re: Add Information during standby recovery conflicts

From: "Drouvot, Bertrand" <bdrouvot(at)amazon(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add Information during standby recovery conflicts
Date: 2020-11-16 07:55:37
Message-ID: a2003b61-3169-0523-af37-44876248b547@amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 11/16/20 6:44 AM, Masahiko Sawada wrote:
> Thank you for updating the patch.
>
> Here are review comments.
>
> + if (report_waiting && (!logged_recovery_conflict ||
> new_status == NULL))
> + ts = GetCurrentTimestamp();
>
> The condition will always be true if log_recovery_conflict_wait is
> false and report_waiting is true, leading to unnecessary calling of
> GetCurrentTimestamp().
>
> ---
> + <para>
> + You can control whether a log message is produced when the startup process
> + is waiting longer than <varname>deadlock_timeout</varname> for recovery
> + conflicts. This is controled by the <xref
> linkend="guc-log-recovery-conflict-waits"/>
> + parameter.
> + </para>
>
> s/controled/controlled/
>
> ---
> if (report_waiting)
> waitStart = GetCurrentTimestamp();
>
> Similarly, we have the above code but we don't need to call
> GetCurrentTimestamp() if update_process_title is false, even if
> report_waiting is true.
>
> I've attached the patch that fixes the above comments. It can be
> applied on top of your v8 patch.

Thanks for the review and the associated fixes!

I've attached a new version that contains your fixes.

Thanks

Bertrand

Attachment Content-Type Size
v8-0004-Log-the-standby-recovery-conflict-waits.patch text/plain 16.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2020-11-16 07:56:06 Re: PostmasterIsAlive() in recovery (non-USE_POST_MASTER_DEATH_SIGNAL builds)
Previous Message Masahiro Ikeda 2020-11-16 07:35:23 Re: Add statistics to pg_stat_wal view for wal related parameter tuning