| From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
|---|---|
| To: | nitinjadhavpostgres(at)gmail(dot)com |
| Cc: | adam8157(at)gmail(dot)com, michael(at)paquier(dot)xyz, hlinnaka(at)iki(dot)fi, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: [PATCH] Fix minRecoveryPoint not advanced past checkpoint in CreateRestartPoint |
| Date: | 2026-06-10 04:53:35 |
| Message-ID: | 20260610.135335.1492475965692488167.horikyota.ntt@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Peter Smith | 2026-06-10 04:36:44 | Re: Support EXCEPT for TABLES IN SCHEMA publications |