Remove log_checkpoints = true from .pl tests
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.
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:t46401psql -h localhost -U postgresBuilt from patchset v1 (message #1), August 27, 2026 at 05:44 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 t46401_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 t46401_1 && git checkout t46401_1Patchset v1 (message #1) is on t46401_1
Hi,
With commit 64da07c41a8c0a680460cdafc79093736332b6cf making default
value of log_checkpoints to on, do we need to remove explicit settings
in perl tests to save some (5) LOC?
Although, it's harmless, here's a tiny patch to remove them.
--
Bharath Rupireddy
RDS Open Source Databases: https://aws.amazon.com/rds/postgresql/
Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> writes:
With commit 64da07c41a8c0a680460cdafc79093736332b6cf making default
value of log_checkpoints to on, do we need to remove explicit settings
in perl tests to save some (5) LOC?
I'm not particularly eager to do that, because I think defaulting
log_checkpoints to "on" was a bad decision that will eventually get
reverted. Even if that doesn't happen, we have *far* better ways
to spend our time than removing five lines of code, or even
discussing whether to do so.
regards, tom lane