Date: Tue, 18 Aug 2020 17:52:39 -0500
From: Justin Pryzby <pryzby@telsasoft.com>
To: pgsql-hackers@postgresql.org
Subject: please update ps display for recovery checkpoint
Message-ID: <20200818225238.GP17022@telsasoft.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="xJK8B5Wah2CMJs8h"
Content-Disposition: inline
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk


--xJK8B5Wah2CMJs8h
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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.com

-- 
Justin

--xJK8B5Wah2CMJs8h
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
 filename="0001-Update-PS-display-following-replay-of-last-xlog.patch"

From 93c716bbbb0f39bf63593e10d7730160668016d7 Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Sat, 8 Feb 2020 09:16:14 -0600
Subject: [PATCH 1/3] Update PS display following replay of last xlog..

..otherwise it shows "recovering <file>" for the duration of the recovery
checkpoint.
---
 src/backend/access/transam/xlog.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 09c01ed4ae..8e08ce09da 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -7765,7 +7765,10 @@ StartupXLOG(void)
 								  CHECKPOINT_WAIT);
 		}
 		else
+		{
+			set_ps_display("recovery checkpoint");
 			CreateCheckPoint(CHECKPOINT_END_OF_RECOVERY | CHECKPOINT_IMMEDIATE);
+		}
 	}
 
 	if (ArchiveRecoveryRequested)
-- 
2.17.0


--xJK8B5Wah2CMJs8h
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
 filename="0002-Document-that-checkpoint_flush_after-applies-to-end-.patch"

From 78e6ad73352240849982452ed1fb4cd0b8ed303e Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Sat, 18 Jan 2020 13:44:08 -0600
Subject: [PATCH 2/3] Document that checkpoint_flush_after applies to
 end-of-recovery checkpoint

---
 doc/src/sgml/config.sgml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 7a7177c550..c0b5422599 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -3175,6 +3175,8 @@ include_dir 'conf.d'
         that are bigger than <xref linkend="guc-shared-buffers"/>, but smaller
         than the OS's page cache, where performance might degrade.  This
         setting may have no effect on some platforms.
+        This setting also applies to the checkpoint written at the end of crash
+        recovery.
         If this value is specified without units, it is taken as blocks,
         that is <symbol>BLCKSZ</symbol> bytes, typically 8kB.
         The valid range is
-- 
2.17.0


--xJK8B5Wah2CMJs8h
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="0003-Avoid-ambiguous-that.patch"

From 8f27859d6ed5ee69773171c79cc9c26a18f65a67 Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Sat, 18 Jan 2020 13:44:33 -0600
Subject: [PATCH 3/3] Avoid ambiguous "that"

---
 doc/src/sgml/config.sgml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index c0b5422599..84b40467b3 100644
--- 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
-- 
2.17.0


--xJK8B5Wah2CMJs8h--