Subject: Re: [PATCH] Expose checkpoint reason to completion log messages.

From: Soumya S Murali <[email-masked]>
Date: Thu, 8 Jan 2026 11:58:43 +0530

Hi all,

On Wed, Jan 7, 2026 at 1:37 PM Michael Banck <[email-masked]> wrote:
>
> Hi,
>
> On Wed, Jan 07, 2026 at 12:35:08PM +0530, Soumya S Murali wrote:
> > I agree with your point that the checkpoint completion message should
> > use the same terminology as the starting message ( “fast” rather than
> > “immediate”) and I have updated the patch accordingly and have
> > attached herewith for review. This patch aligns the checkpoint
> > completion log wording with the existing checkpoint starting message
> > (using “fast” instead of “immediate”) for consistency.
>
> First off, please send complete and not incremental patches.
>
> From what I can tell, you currently also do not have "wal" as reason?
> Also, you have "timed" vs "time" etc.
>
> I think it would make most sense to factor out the logic for the
> starting checkpoint reason from xlog.c ("(errmsg("checkpoint
> starting:%s%s%s%s%s%s%s%s")") and use that both for starting and
> stopping.
>
>
> Michael

Thank you for the review and feedback.
I have reworked the patch to factor out the checkpoint reason logic to
use the same wording for both checkpoint start and completion log
(including wal, time, fast, force, and wait). The format has been
aligned with existing conventions and has been verified by running
make check and recovery TAP tests including t/019_replslot_limit.pl
successfully.
Kindly review my patch and let me know the feedback.

Regards,
Soumya
From 0204328b225d5641a13e3e6f4c373622df31a398 Mon Sep 17 00:00:00 2001
From: Soumya <[email-masked]>
Date: Thu, 8 Jan 2026 11:42:23 +0530
Subject: [PATCH] Expose checkpoint reason in checkpoint completion log
 messages

Signed-off-by: Soumya <[email-masked]>
---
 src/backend/access/transam/xlog.c         | 51 ++++++++++++++++++-----
 src/test/recovery/t/019_replslot_limit.pl |  2 +-
 2 files changed, 41 insertions(+), 12 deletions(-)

diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 22d0a2e8c3..9f7439f9a2 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -203,6 +203,8 @@ const struct config_enum_entry archive_mode_options[] = {
 	{NULL, 0, false}
 };
 
+static char checkpoint_reason_str[128];
+
 /*
  * Statistics for current checkpoint are collected in this global struct.
  * Because only the checkpointer or a stand-alone backend can perform
@@ -6714,12 +6716,47 @@ ShutdownXLOG(int code, Datum arg)
 	}
 }
 
+/*
+ * Format checkpoint reason flags consistently for log messages.
+ * The returned string is suitable for inclusion after
+ * "checkpoint starting:" or inside "checkpoint complete (...)".
+ */
+static const char *
+CheckpointReasonString(int flags)
+{
+	static char buf[128];
+
+	buf[0] = '\0';
+
+	if (flags & CHECKPOINT_IS_SHUTDOWN)
+		strcat(buf, " shutdown");
+	if (flags & CHECKPOINT_END_OF_RECOVERY)
+		strcat(buf, " end-of-recovery");
+	if (flags & CHECKPOINT_FAST)
+		strcat(buf, " fast");
+	if (flags & CHECKPOINT_FORCE)
+		strcat(buf, " force");
+	if (flags & CHECKPOINT_WAIT)
+		strcat(buf, " wait");
+	if (flags & CHECKPOINT_CAUSE_XLOG)
+		strcat(buf, " wal");
+	if (flags & CHECKPOINT_CAUSE_TIME)
+		strcat(buf, " time");
+	if (flags & CHECKPOINT_FLUSH_UNLOGGED)
+		strcat(buf, " flush-unlogged");
+
+	return buf;
+}
+
 /*
  * Log start of a checkpoint.
  */
 static void
 LogCheckpointStart(int flags, bool restartpoint)
 {
+	strlcpy(checkpoint_reason_str,
+        	CheckpointReasonString(flags),
+        	sizeof(checkpoint_reason_str));
 	if (restartpoint)
 		ereport(LOG,
 		/* translator: the placeholders show checkpoint options */
@@ -6734,16 +6771,7 @@ LogCheckpointStart(int flags, bool restartpoint)
 						(flags & CHECKPOINT_FLUSH_UNLOGGED) ? " flush-unlogged" : "")));
 	else
 		ereport(LOG,
-		/* translator: the placeholders show checkpoint options */
-				(errmsg("checkpoint starting:%s%s%s%s%s%s%s%s",
-						(flags & CHECKPOINT_IS_SHUTDOWN) ? " shutdown" : "",
-						(flags & CHECKPOINT_END_OF_RECOVERY) ? " end-of-recovery" : "",
-						(flags & CHECKPOINT_FAST) ? " fast" : "",
-						(flags & CHECKPOINT_FORCE) ? " force" : "",
-						(flags & CHECKPOINT_WAIT) ? " wait" : "",
-						(flags & CHECKPOINT_CAUSE_XLOG) ? " wal" : "",
-						(flags & CHECKPOINT_CAUSE_TIME) ? " time" : "",
-						(flags & CHECKPOINT_FLUSH_UNLOGGED) ? " flush-unlogged" : "")));
+        		(errmsg("checkpoint starting:%s", checkpoint_reason_str)));
 }
 
 /*
@@ -6824,12 +6852,13 @@ LogCheckpointEnd(bool restartpoint)
 						LSN_FORMAT_ARGS(ControlFile->checkPointCopy.redo))));
 	else
 		ereport(LOG,
-				(errmsg("checkpoint complete: wrote %d buffers (%.1f%%), "
+				(errmsg("checkpoint complete (%s): wrote %d buffers (%.1f%%), "
 						"wrote %d SLRU buffers; %d WAL file(s) added, "
 						"%d removed, %d recycled; write=%ld.%03d s, "
 						"sync=%ld.%03d s, total=%ld.%03d s; sync files=%d, "
 						"longest=%ld.%03d s, average=%ld.%03d s; distance=%d kB, "
 						"estimate=%d kB; lsn=%X/%08X, redo lsn=%X/%08X",
+						checkpoint_reason_str,
 						CheckpointStats.ckpt_bufs_written,
 						(double) CheckpointStats.ckpt_bufs_written * 100 / NBuffers,
 						CheckpointStats.ckpt_slru_written,
diff --git a/src/test/recovery/t/019_replslot_limit.pl b/src/test/recovery/t/019_replslot_limit.pl
index 6468784b83..ccc363157e 100644
--- a/src/test/recovery/t/019_replslot_limit.pl
+++ b/src/test/recovery/t/019_replslot_limit.pl
@@ -203,7 +203,7 @@ is($result, "rep1|f|t|lost|",
 my $checkpoint_ended = 0;
 for (my $i = 0; $i < 10 * $PostgreSQL::Test::Utils::timeout_default; $i++)
 {
-	if ($node_primary->log_contains("checkpoint complete: ", $logstart))
+	if ($node_primary->log_contains(qr/checkpoint complete(?: \([^)]*\))?:/, $logstart))
 	{
 		$checkpoint_ended = 1;
 		last;
-- 
2.34.1

---

From: li carol <[email-masked]>
Date: Thu, 8 Jan 2026 13:31:49 +0000

> > > I agree with your point that the checkpoint completion message
> > > should use the same terminology as the starting message ( “fast”
> > > rather than
> I have reworked the patch to factor out the checkpoint reason logic to use the
> same wording for both checkpoint start and completion log (including wal, time,
> fast, force, and wait). The format has been aligned with existing conventions
> and has been verified by running make check and recovery TAP tests including
> t/019_replslot_limit.pl successfully.

Hi Soumya,

Thanks for the updated patch. I agree that having the checkpoint reason in the completion log is very helpful for performance analysis, as it avoids the need to manually correlate "starting" and "complete" messages in busy logs.
I’ve reviewed the latest version and have a few suggestions to make the refactoring more complete:
1. Consistency in LogCheckpointStart
Currently, the checkpoint branch uses the new CheckpointReasonString helper, but the restartpoint branch still uses the old inline triple-operator logic. It would be better to use the helper function in both places to ensure they stay in sync.

2. Missing Reason for Restartpoints 
In LogCheckpointEnd, the checkpoint reason is added to the checkpoint complete message, but the restartpoint complete message remains unchanged. I think users would find the reason for restartpoints just as useful for debugging.

3. Global Variable vs. Passing Flags: Instead of using a file-level global checkpoint_reason_str to pass data between the start and end functions, would it make sense to simply pass the flags as a new argument to LogCheckpointEnd(bool restartpoint, int flags)? 
This would allow you to call the helper function directly inside the ereport calls and avoid maintaining global state.

4. Whitespace Errors: I noticed a few whitespace warnings (space before tabs) when applying the patch. 
/home/carol/0001-Expose-checkpoint-reason-in-checkpoint-completion-lo.patch:69: space before tab in indent.
        	CheckpointReasonString(flags),
/home/carol/0001-Expose-checkpoint-reason-in-checkpoint-completion-lo.patch:70: space before tab in indent.
        	sizeof(checkpoint_reason_str));
/home/carol/0001-Expose-checkpoint-reason-in-checkpoint-completion-lo.patch:88: space before tab in indent.
        		(errmsg("checkpoint starting:%s", checkpoint_reason_str)));
warning: 3 lines add whitespace errors.

The patch can be compiled successfully and can pass make check -C src/test/recovery/

Regards,
Yuan Li(carol)

---

From: Michael Banck <[email-masked]>
Date: Thu, 8 Jan 2026 18:36:13 +0100

Hi,

> Kindly review my patch and let me know the feedback.

Thanks for the new patch.

> +++ b/src/backend/access/transam/xlog.c
[...]
> +		strcat(buf, " flush-unlogged");

The way this is coded now prepends the final string with a space
character. This is fine for the checkpoint starting message, but makes
the checkpoint finished message look slightly weird (not the "( wal)"):

|2026-01-08 18:30:33.691 CET [1666416] LOG:  checkpoint complete ( wal):
|wrote 20 buffers (0.1%), wrote 0 SLRU buffers; 0 WAL file(s) added, 4
|removed, 33 recycled; write=2.221 s, sync=0.019 s, total=2.701 s; sync
|files=3, longest=0.018 s, average=0.007 s; distance=601885 kB,
|estimate=601885 kB; lsn=0/D2D59FC8, redo lsn=0/B492B500

Also I think the translators might now complain, but I am not sure how
to best approach this.

Michael

---

From: Soumya S Murali <[email-masked]>
Date: Mon, 12 Jan 2026 12:53:54 +0530

Hi all,

> Also I think the translators might now complain, but I am not sure how

Based on the feedback received, I have reworked and implemented a
helper function so that both checkpoint start and completion messages
use the same wording and would remain in sync, extending the same
reason reporting to restart points for completeness and better
observability, ensuring consistent terminology with existing log
output, had removed the previous use of global state and instead
passed checkpoint flags explicitly and have fixed formatting and
whitespace issues noted during review.
Also, I have tested and validated the logic successfully. I have
attached the updated patch for further review.
Kindly review the patch and let me know the feedback.

Regards,
Soumya
From 30e3c62695a643daf96ffca3b504a79d2a761f77 Mon Sep 17 00:00:00 2001
From: Soumya <[email-masked]>
Date: Mon, 12 Jan 2026 12:36:29 +0530
Subject: [PATCH] Expose checkpoint reason in completion log messages

---
 src/backend/access/transam/xlog.c         | 78 ++++++++++++++++-------
 src/test/recovery/t/019_replslot_limit.pl |  2 +-
 2 files changed, 55 insertions(+), 25 deletions(-)

diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 22d0a2e8c3..63d1e56ca1 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -6714,6 +6714,49 @@ ShutdownXLOG(int code, Datum arg)
 	}
 }
 
+/*
+* Format checkpoint reason flags consistently for log messages.
+* The returned string is suitable for inclusion after
+* "checkpoint starting:" or inside "checkpoint complete (...)".
+*/
+static const char *
+CheckpointReasonString(int flags)
+{
+	static char buf[128];
+	bool first = true;
+
+	buf[0] = '\0';
+
+#define APPEND_REASON(str)			\
+	do {							\
+		if (!first)				\
+			strcat(buf, " ");		\
+		strcat(buf, (str));		\
+		first = false;			\
+	} while (0)
+
+	if (flags & CHECKPOINT_IS_SHUTDOWN)
+		APPEND_REASON("shutdown");
+	if (flags & CHECKPOINT_END_OF_RECOVERY)
+		APPEND_REASON("end-of-recovery");
+	if (flags & CHECKPOINT_FAST)
+		APPEND_REASON("fast");
+	if (flags & CHECKPOINT_FORCE)
+		APPEND_REASON("force");
+	if (flags & CHECKPOINT_WAIT)
+		APPEND_REASON("wait");
+	if (flags & CHECKPOINT_CAUSE_XLOG)
+		APPEND_REASON("wal");
+	if (flags & CHECKPOINT_CAUSE_TIME)
+		APPEND_REASON("time");
+	if (flags & CHECKPOINT_FLUSH_UNLOGGED)
+		APPEND_REASON("flush-unlogged");
+
+#undef APPEND_REASON
+
+	return buf;
+}
+
 /*
  * Log start of a checkpoint.
  */
@@ -6723,34 +6766,19 @@ LogCheckpointStart(int flags, bool restartpoint)
 	if (restartpoint)
 		ereport(LOG,
 		/* translator: the placeholders show checkpoint options */
-				(errmsg("restartpoint starting:%s%s%s%s%s%s%s%s",
-						(flags & CHECKPOINT_IS_SHUTDOWN) ? " shutdown" : "",
-						(flags & CHECKPOINT_END_OF_RECOVERY) ? " end-of-recovery" : "",
-						(flags & CHECKPOINT_FAST) ? " fast" : "",
-						(flags & CHECKPOINT_FORCE) ? " force" : "",
-						(flags & CHECKPOINT_WAIT) ? " wait" : "",
-						(flags & CHECKPOINT_CAUSE_XLOG) ? " wal" : "",
-						(flags & CHECKPOINT_CAUSE_TIME) ? " time" : "",
-						(flags & CHECKPOINT_FLUSH_UNLOGGED) ? " flush-unlogged" : "")));
+				(errmsg("restartpoint starting: %s",
+						CheckpointReasonString(flags))));
 	else
 		ereport(LOG,
-		/* translator: the placeholders show checkpoint options */
-				(errmsg("checkpoint starting:%s%s%s%s%s%s%s%s",
-						(flags & CHECKPOINT_IS_SHUTDOWN) ? " shutdown" : "",
-						(flags & CHECKPOINT_END_OF_RECOVERY) ? " end-of-recovery" : "",
-						(flags & CHECKPOINT_FAST) ? " fast" : "",
-						(flags & CHECKPOINT_FORCE) ? " force" : "",
-						(flags & CHECKPOINT_WAIT) ? " wait" : "",
-						(flags & CHECKPOINT_CAUSE_XLOG) ? " wal" : "",
-						(flags & CHECKPOINT_CAUSE_TIME) ? " time" : "",
-						(flags & CHECKPOINT_FLUSH_UNLOGGED) ? " flush-unlogged" : "")));
+				(errmsg("checkpoint starting: %s",
+						CheckpointReasonString(flags))));
 }
 
 /*
  * Log end of a checkpoint.
  */
 static void
-LogCheckpointEnd(bool restartpoint)
+LogCheckpointEnd(bool restartpoint, int flags)
 {
 	long		write_msecs,
 				sync_msecs,
@@ -6800,12 +6828,13 @@ LogCheckpointEnd(bool restartpoint)
 	 */
 	if (restartpoint)
 		ereport(LOG,
-				(errmsg("restartpoint complete: wrote %d buffers (%.1f%%), "
+				(errmsg("restartpoint complete (%s): wrote %d buffers (%.1f%%), "
 						"wrote %d SLRU buffers; %d WAL file(s) added, "
 						"%d removed, %d recycled; write=%ld.%03d s, "
 						"sync=%ld.%03d s, total=%ld.%03d s; sync files=%d, "
 						"longest=%ld.%03d s, average=%ld.%03d s; distance=%d kB, "
 						"estimate=%d kB; lsn=%X/%08X, redo lsn=%X/%08X",
+						CheckpointReasonString(flags),
 						CheckpointStats.ckpt_bufs_written,
 						(double) CheckpointStats.ckpt_bufs_written * 100 / NBuffers,
 						CheckpointStats.ckpt_slru_written,
@@ -6824,12 +6853,13 @@ LogCheckpointEnd(bool restartpoint)
 						LSN_FORMAT_ARGS(ControlFile->checkPointCopy.redo))));
 	else
 		ereport(LOG,
-				(errmsg("checkpoint complete: wrote %d buffers (%.1f%%), "
+				(errmsg("checkpoint complete (%s): wrote %d buffers (%.1f%%), "
 						"wrote %d SLRU buffers; %d WAL file(s) added, "
 						"%d removed, %d recycled; write=%ld.%03d s, "
 						"sync=%ld.%03d s, total=%ld.%03d s; sync files=%d, "
 						"longest=%ld.%03d s, average=%ld.%03d s; distance=%d kB, "
 						"estimate=%d kB; lsn=%X/%08X, redo lsn=%X/%08X",
+						CheckpointReasonString(flags),
 						CheckpointStats.ckpt_bufs_written,
 						(double) CheckpointStats.ckpt_bufs_written * 100 / NBuffers,
 						CheckpointStats.ckpt_slru_written,
@@ -7418,7 +7448,7 @@ CreateCheckPoint(int flags)
 		TruncateSUBTRANS(GetOldestTransactionIdConsideredRunning());
 
 	/* Real work is done; log and update stats. */
-	LogCheckpointEnd(false);
+	LogCheckpointEnd(false, flags);
 
 	/* Reset the process title */
 	update_checkpoint_display(flags, false, true);
@@ -7886,7 +7916,7 @@ CreateRestartPoint(int flags)
 		TruncateSUBTRANS(GetOldestTransactionIdConsideredRunning());
 
 	/* Real work is done; log and update stats. */
-	LogCheckpointEnd(true);
+	LogCheckpointEnd(true, flags);
 
 	/* Reset the process title */
 	update_checkpoint_display(flags, true, true);

---

From: Michael Banck <[email-masked]>
Date: Mon, 12 Jan 2026 11:26:58 +0100

Hi,

> +* "checkpoint starting:" or inside "checkpoint complete (...)".

Indentation of the comment is wrong here, the asterisks should be all on
the same column.
> +CheckpointReasonString(int flags)

pgindent complains about the above line as well:

| {
|        static char buf[128];
|-       bool first = true;
|+       bool            first = true;
| 
|        buf[0] = '\0';
 
> +#define APPEND_REASON(str)			\

Those ending backslashes also don't seem to line up when 4-space tabs
are set. But pgindent doesn't change them so maybe it is correct as-is?

I am also not sure whether the above is current best-practise for
Postgres code, I'd have to look deeper (or maybe somebody else can
review this).

> +		APPEND_REASON("flush-unlogged");

I am still not sure whether this will be a regression for translation of
those strings.

Otherwise, the patch looks sane to me.

Michael

---

From: Soumya S Murali <[email-masked]>
Date: Tue, 13 Jan 2026 11:59:43 +0530

Hi all,

> Otherwise, the patch looks sane to me.

Thank you for the detailed review and suggestions.
I have reworked the patch on a fresh tree, addressed the formatting
and indentation issues, and aligned the helper implementation with
PostgreSQL coding conventions. The updated patch has been pgindented
and validated with make check and the full recovery TAP test suite. I
am attaching the revised patch for further review.

Regards,
Soumya
From c2ed1eb81b38c36399b8fbec5bf09326b06fefa0 Mon Sep 17 00:00:00 2001
From: Soumya <[email-masked]>
Date: Tue, 13 Jan 2026 11:50:53 +0530
Subject: [PATCH] Expose checkpoint reason in completion log messages

Signed-off-by: Soumya <[email-masked]>
---
 src/backend/access/transam/xlog.c         | 79 ++++++++++++++++-------
 src/test/recovery/t/019_replslot_limit.pl |  2 +-
 2 files changed, 56 insertions(+), 25 deletions(-)

diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 22d0a2e8c3..8cdf2b23c3 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -6714,6 +6714,50 @@ ShutdownXLOG(int code, Datum arg)
 	}
 }
 
+/*
+	do                                              \
+	{                                               \
@@ -6723,34 +6767,19 @@ LogCheckpointStart(int flags, bool restartpoint)
 
 /*
@@ -6800,12 +6829,13 @@ LogCheckpointEnd(bool restartpoint)
@@ -6824,12 +6854,13 @@ LogCheckpointEnd(bool restartpoint)
@@ -7418,7 +7449,7 @@ CreateCheckPoint(int flags)

 	/* Reset the process title */
 	update_checkpoint_display(flags, false, true);
@@ -7886,7 +7917,7 @@ CreateRestartPoint(int flags)
 		TruncateSUBTRANS(GetOldestTransactionIdConsideredRunning());

---

From: Fujii Masao <[email-masked]>
Date: Tue, 13 Jan 2026 22:09:49 +0900

> am attaching the revised patch for further review.

Thanks for updating the patch!

With this patch, the checkpoint log messages look like this:

    LOG:  checkpoint starting: fast force wait
    LOG:  checkpoint complete (fast force wait): ...

The formatting of the checkpoint flags differs between the starting and
complete messages: the complete message wraps them in parentheses,
while the starting message does not. I think it would be better to log
the flags in a consistent way in both messages. For example:

    LOG:  checkpoint starting: fast force wait
    LOG:  checkpoint complete: fast force wait: ...

- if ($node_primary->log_contains("checkpoint complete: ", $logstart))
+ if ($node_primary->log_contains(qr/checkpoint complete(?:
\([^)]*\))?:/, $logstart))

If we adopt a format like the above example, this test change would
no longer be needed.

Wouldn't it be simpler to just build the string with snprintf() based on
the flags? For example:

---------------------------------------------------
static char buf[128];

snprintf(buf, sizeof(buf), "%s%s%s%s%s%s%s%s",
(flags & CHECKPOINT_IS_SHUTDOWN) ? " shutdown" : "",
(flags & CHECKPOINT_END_OF_RECOVERY) ? " end-of-recovery" : "",
(flags & CHECKPOINT_FAST) ? " fast" : "",
(flags & CHECKPOINT_FORCE) ? " force" : "",
(flags & CHECKPOINT_WAIT) ? " wait" : "",
(flags & CHECKPOINT_CAUSE_XLOG) ? " wal" : "",
(flags & CHECKPOINT_CAUSE_TIME) ? " time" : "",
(flags & CHECKPOINT_FLUSH_UNLOGGED) ? " flush-unlogged" : "");

return buf;
---------------------------------------------------

These flags include more than just the reason a checkpoint was triggered,
so using "reason" here seems misleading. Wouldn't just "flags" be a better term?

Regards,

-- 
Fujii Masao

---

From: Soumya S Murali <[email-masked]>
Date: Wed, 14 Jan 2026 15:41:36 +0530

Hi all,

Thank you for the detailed review and suggestions.
Based on the feedback, I have updated the patch to make the checkpoint
and restart point log formatting fully consistent between start and
completion log messages. The completion messages now use the same
format as the start messages without parentheses. I have also replaced
the term "reason" with the term "flags". The patch has been rebuilt
and validated with make check and the full recovery TAP test suite,
and I have manually verified the resulting log output to confirm the
expected formatting. I am attaching the updated patch for further
review. Please let me know if any additional adjustments are needed.

Regards,
Soumya
From 6987dad63e07700bbde9e095516f880719b9c729 Mon Sep 17 00:00:00 2001
From: Soumya <[email-masked]>
Date: Wed, 14 Jan 2026 15:32:29 +0530
Subject: [PATCH] Expose checkpoint reason in completion log messages

index 22d0a2e8c3..881e656f25 100644
 
+/*
+CheckpointFlagsString(int flags)
+						CheckpointFlagsString(flags))));
+						CheckpointFlagsString(flags))));
 }
 
 /*
+				(errmsg("restartpoint complete: %s: wrote %d buffers (%.1f%%), "
+						CheckpointFlagsString(flags),
+				(errmsg("checkpoint complete: %s: wrote %d buffers (%.1f%%), "
+						CheckpointFlagsString(flags),

 
 
index 6468784b83..ad2088ef3a 100644
+	if ($node_primary->log_contains("checkpoint complete:", $logstart))
 	{
 		$checkpoint_ended = 1;
 		last;
-- 
2.34.1

---

From: Fujii Masao <[email-masked]>
Date: Tue, 17 Feb 2026 14:55:29 +0900

I still think it would be simpler to construct the checkpoint flags string
with snprintf() rather than introducing a new macro. Please see
the attached patch.

I don't think this change is necessary.

I've also updated the commit message in the attached patch.

Regards,

-- 
Fujii Masao

---

From: Soumya S Murali <[email-masked]>
Date: Tue, 17 Feb 2026 16:17:48 +0530

Hi all,

> I've also updated the commit message in the attached patch.

Thank you very much for refining the implementation and simplifying
the flag construction logic using snprintf(). I have reviewed the
committed changes and verified that the formatting and behavior are
consistent and correct. The updated approach is clear and aligns well
with PostgreSQL coding style. I also appreciate the improvements made
to the commit message as it clearly explains the motivation and makes
the change easy to understand in context.
I sincerely appreciate your guidance throughout this review process.

Regards,
Soumya

---

From: Fujii Masao <[email-masked]>
Date: Thu, 19 Feb 2026 23:57:24 +0900

> the change easy to understand in context.

I've pushed the patch. Thanks!

Regards,

-- 
Fujii Masao

---

From: Soumya S Murali <[email-masked]>
Date: Fri, 20 Feb 2026 10:55:48 +0530

Hi all,

> I've pushed the patch. Thanks!

Thank you so much for pushing the patch. I truly appreciate your
guidance and the detailed review throughout this process. It has been
a valuable learning experience.
Thank you.

Regards,
Soumya