From: Justin Pryzby <pryzby@telsasoft.com>
To: pgsql-hackers@postgresql.org
Subject: please update ps display for recovery checkpoint
Date: Tue, 18 Aug 2020 17:52:39 -0500
Message-ID: <20200818225238.GP17022@telsasoft.com> (raw)
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
Attachments:
[text/x-diff] 0001-Update-PS-display-following-replay-of-last-xlog.patch (847B, ../20200818225238.GP17022@telsasoft.com/2-0001-Update-PS-display-following-replay-of-last-xlog.patch)
download | inline diff:
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.cindex 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
[text/x-diff] 0002-Document-that-checkpoint_flush_after-applies-to-end-.patch (1012B, ../20200818225238.GP17022@telsasoft.com/3-0002-Document-that-checkpoint_flush_after-applies-to-end-.patch)
download | inline diff:
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.sgmlindex 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
[text/x-diff] 0003-Avoid-ambiguous-that.patch (1.1K, ../20200818225238.GP17022@telsasoft.com/4-0003-Avoid-ambiguous-that.patch)
download | inline diff:
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.sgmlindex 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: pryzby@telsasoft.com
Subject: Re: please update ps display for recovery checkpoint
In-Reply-To: <20200818225238.GP17022@telsasoft.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox