Stabilize 026_overwrite_contrecord test
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
This thread has been committed, so CI has stopped here. Anything below is the last result it produced.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t253651psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 08, 2026 at 12:02 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t253651_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t253651_1 && git checkout t253651_1Patchset v1 (message #1) is on t253651_1
Hi,
I investigated the 026_overwrite_contrecord.pl test failure reported by
buildfarm member skink [1]https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2026-09-02%2020%3A46%3A37, since it occurred just after commit
5d13f753054 that I pushed. The failure seems unrelated to that commit,
though.
The test failed while starting the standby:
31/324 recovery - postgresql:recovery/026_overwrite_contrecord
ERROR 324.69s (exit status 255 or 0xff)
The primary took long enough to generate WAL that a time-based checkpoint
occurred before the test stopped it:
LOG: checkpoint starting: time
LOG: checkpoint complete: ... lsn=0/2093DC8, redo lsn=0/1F8F6A0
The test then removed the tail WAL segment as part of its test scenario.
Because the checkpoint record was in that segment, the standby initialized
from the resulting backup could not find the checkpoint record and failed
with a PANIC:
LOG: invalid checkpoint record
PANIC: could not locate a valid checkpoint record at 0/2093DC8
So, it seems that the unrelated checkpoint activity caused the test
failure.
The attached patch fixes this by setting checkpoint_timeout high enough
to prevent unrelated checkpoints during this test. This follows the same
approach used by other recovery tests, such as 043_no_contrecord_switch.pl.
Thoughts?
Regards,
[1]: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2026-09-02%2020%3A46%3A37
--
Fujii Masao
On Thu, Sep 03, 2026 at 09:28:22AM +0900, Fujii Masao wrote:
The attached patch fixes this by setting checkpoint_timeout high enough
to prevent unrelated checkpoints during this test. This follows the same
approach used by other recovery tests, such as 043_no_contrecord_switch.pl.
Yes, this failure is also something that was puzzling me a bit, but I
did not take the time to dig into it. Enforcing a larger checkpoint
timeout sounds like a safety measure good enough, at quick glance.
Thanks.
--
Michael
Hello Michael and Fujii-san,
03.09.2026 03:33, Michael Paquier wrote:
On Thu, Sep 03, 2026 at 09:28:22AM +0900, Fujii Masao wrote:
The attached patch fixes this by setting checkpoint_timeout high enough
to prevent unrelated checkpoints during this test. This follows the same
approach used by other recovery tests, such as 043_no_contrecord_switch.pl.Yes, this failure is also something that was puzzling me a bit, but I
did not take the time to dig into it. Enforcing a larger checkpoint
timeout sounds like a safety measure good enough, at quick glance.
Please look at:
https://wiki.postgresql.org/wiki/Known_Buildfarm_Test_Failures
where all such failures are enumerated with links to corresponding
reports/discussions, e.g. I reported this one previously:
/messages/by-id/9ffdb19a-7a89-424e-925a-dd981c37f0ba@gmail.com
Best regards,
Alexander
On Fri, Sep 4, 2026 at 2:00 AM Alexander Lakhin <exclusion@gmail.com> wrote:
03.09.2026 03:33, Michael Paquier wrote:
Yes, this failure is also something that was puzzling me a bit, but I
did not take the time to dig into it. Enforcing a larger checkpoint
timeout sounds like a safety measure good enough, at quick glance.
Thanks!
where all such failures are enumerated with links to corresponding
reports/discussions, e.g. I reported this one previously:
/messages/by-id/9ffdb19a-7a89-424e-925a-dd981c37f0ba@gmail.com
Thanks for the pointer!
Reading your previous report, my understanding is that the failure was
also caused by a checkpoint during the test. So the proposed fix, which
increases checkpoint_timeout to prevent such checkpoints,
seems consistent with that analysis.
So, barring any objections, I'll commit the patch.
Regards,
--
Fujii Masao