RE: please update ps display for recovery checkpoint

From: "k(dot)jamison(at)fujitsu(dot)com" <k(dot)jamison(at)fujitsu(dot)com>
To: 'Justin Pryzby' <pryzby(at)telsasoft(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: please update ps display for recovery checkpoint
Date: 2020-08-19 00:20:50
Message-ID: OSBPR01MB2341D2D3141FB3E4C97A0B4DEF5D0@OSBPR01MB2341.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wednesday, August 19, 2020 7:53 AM (GMT+9), Justin Pryzby wrote:

Hi,

All the patches apply, although when applying them the following appears:
(Stripping trailing CRs from patch; use --binary to disable.)

> During crash recovery, the server writes this to log:
>
> < 2020-08-16 08:46:08.601 -03 >LOG: redo done at 2299C/1EC6BA00 <
> 2020-08-16 08:46:08.877 -03 >LOG: checkpoint starting: end-of-recovery
> immediate
>
> But runs a checkpoint, which can take a long time, while the "ps" display still says
> "recovering NNNNNNNN".
>
> Please change to say "recovery checkpoint" or similar, as I mentioned here.
> https://www.postgresql.org/message-id/20200118201111.GP26045@telsasoft.c
> om

Yes, I agree that it is helpful to tell users about that.

About 0003 patch, there are similar phrases in bgwriter_flush_after and
backend_flush_after. Should those be updated too?

--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -3170,7 +3170,7 @@ include_dir 'conf.d'
limit the amount of dirty data in the kernel's page cache, reducing
the likelihood of stalls when an <function>fsync</function> is issued at the end of the
checkpoint, or when the OS writes data back in larger batches in the
- background. Often that will result in greatly reduced transaction
+ background. This feature will often result in greatly reduced transaction
latency, but there also are some cases, especially with workloads
that are bigger than <xref linkend="guc-shared-buffers"/>, but smaller
than the OS's page cache, where performance might degrade. This

Regards,
Kirk Jamison

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message torikoshia 2020-08-19 00:43:50 Re: Creating a function for exposing memory usage of backend process
Previous Message Andres Freund 2020-08-18 23:45:32 Re: pgsql: snapshot scalability: cache snapshots using a xact completion co