Date: Wed, 10 Jun 2026 13:53:35 +0900 (JST)
Message-Id: <20260610.135335.1492475965692488167.horikyota.ntt@gmail.com>
To: nitinjadhavpostgres@gmail.com
Cc: adam8157@gmail.com, michael@paquier.xyz, hlinnaka@iki.fi,
 pgsql-hackers@lists.postgresql.org
Subject: Re: [PATCH] Fix minRecoveryPoint not advanced past checkpoint in
 CreateRestartPoint
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
In-Reply-To: 
 <CAMm1aWbCX_Tso1s1oBh6g3=sdvDdZX68gMAN8KRv9Z-1ykiu8w@mail.gmail.com>
References: <adXAXO2qASwOHaQ0@paquier.xyz>
	<adX97VrD4pJKF8zt@MAC-CVW1VHW5R6>
	<CAMm1aWbCX_Tso1s1oBh6g3=sdvDdZX68gMAN8KRv9Z-1ykiu8w@mail.gmail.com>
User-Agent: Mew version 6.8 on Emacs 29.4
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/20260610.135335.1492475965692488167.horikyota.ntt%40gmail.com>
Precedence: bulk

I tend to agree with Michael on the meaning of minRecoveryPoint.

If a tool is using minRecoveryPoint to determine how far recovery has
progressed, then I would say it is looking at the wrong value. I also
do not quite understand what such a tool is trying to verify by
comparing minRecoveryPoint with the recovery target LSN.

If the goal is to verify that recovery reached the configured target,
PostgreSQL already performs that check itself and exits with a FATAL
error otherwise:

>  ereport(FATAL,
>     (errcode(ERRCODE_CONFIG_FILE_ERROR),
>      errmsg("recovery ended before configured recovery target was reached")));

If the underlying use case were explained in more detail, we could
probably have a more concrete discussion about how to address
it. However, I do not think changing the semantics of minRecoveryPoint
is the right solution based on the information available so far.

Regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center