Rename some rel truncation related constants at the top of vacuumlazy.c
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:t46249psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 12:20 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 t46249_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 t46249_1 && git checkout t46249_1Patchset v1 (message #1) is on t46249_1
I propose to rename some of the rel truncation related constants at
the top of vacuumlazy.c, per the attached patch. The patch
consolidates related constants into a single block/grouping, and
imposes a uniform naming scheme.
--
Peter Geoghegan
Peter Geoghegan <pg@bowt.ie> writes:
I propose to rename some of the rel truncation related constants at
the top of vacuumlazy.c, per the attached patch. The patch
consolidates related constants into a single block/grouping, and
imposes a uniform naming scheme.
Um ... you seem to have removed some useful comments?
Personally I wouldn't do this, as I don't think the renaming
brings much benefit, and it will create a hazard for back-patching
any fixes that might be needed in that code. I'm not hugely upset
about it, but that's the way I'd vote if asked.
regards, tom lane
On Mon, Jul 18, 2022 at 8:55 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Um ... you seem to have removed some useful comments?
I don't think that the stuff about making them into a GUC is useful myself.
Personally I wouldn't do this, as I don't think the renaming
brings much benefit, and it will create a hazard for back-patching
any fixes that might be needed in that code. I'm not hugely upset
about it, but that's the way I'd vote if asked.
In that case I withdraw the patch.
FWIW I wrote the patch during the course of work on new feature
development. A patch that added a couple of similar constants a bit
further down. Seemed neater this way, but it's certainly not worth
arguing over.
--
Peter Geoghegan