PATCH pass PGOPTIONS to pg_regress
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:t38786psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 27, 2026 at 08:23 PM.
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 t38786_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 t38786_1 && git checkout t38786_1Patchset v1 (message #1) is on t38786_1
Hi,
attached patch passes PGOPTIONS env variable to pg_regress in pgxs.mk
This is especially useful when developing extensions for different postgres versions
where some session_variables might or might not exists.
Consider something like this in an extensions makefile:
ifeq ($(shell test $(VERSION_NUM) -ge 90600; echo $$?),0)
PGOPTIONS+= "--max_parallel_workers_per_gather=0"
endif
But also when there are many testfiles it might be convenient to align some session parameter globally
In the Makefile.
Thoughts?
Cheers
Manuel Kniep
Hi Manuel,
On 29.05.2018 16:19, Manuel Kniep wrote:
Hi,
attached patch passes PGOPTIONS env variable to pg_regress in
pgxs.mkThis is especially useful when developing extensions for different
postgres versions where some session_variables might or might not
exists.Consider something like this in an extensions makefile:
ifeq ($(shell test $(VERSION_NUM) -ge 90600; echo $$?),0) PGOPTIONS+=
"--max_parallel_workers_per_gather=0" endifBut also when there are many testfiles it might be convenient to
align some session parameter globally In the Makefile.
Have you considered using EXTRA_REGRESS_OPTS variable in extension's
Makefile?
EXTRA_REGRESS_OPTS=--temp-config=$(top_srcdir)/$(subdir)/extra.conf
Here extra.conf is implied to be a file in extension's root directory
which contains additional server options.
This would only work for `make check` though, not `make installcheck`.
--
Ildar Musin
i.musin@postgrespro.ru
On Wed, May 30, 2018 at 12:28:27PM +0300, Ildar Musin wrote:
Here extra.conf is implied to be a file in extension's root directory which
contains additional server options.
This would only work for `make check` though, not `make installcheck`.
REGRESS_OPTS is more widely known for this purpose, and I use it as
well. Still, I agree that there is no need to add an extra mechanism
with PGOPTIONS if a feature already exists. One thing which is also
not much known is that multiple --temp-config entries can be defined
where the last entry wins if the same parameter maps across multiple
files, so you can reduce configuration delta chunks if you need to worry
about multiple versions of the backend for the same development branch
I tend to prefer using one branch per stable version to map with
Postgres and it makes code chunks easier to see without thinking about
PG_VERSION_NUM, still that depends on the project developped.
--
Michael
Am 30.05.2018 um 17:22 schrieb Michael Paquier <michael@paquier.xyz>:
On Wed, May 30, 2018 at 12:28:27PM +0300, Ildar Musin wrote:
Here extra.conf is implied to be a file in extension's root directory which
contains additional server options.
This would only work for `make check` though, not `make installcheck`.REGRESS_OPTS is more widely known for this purpose, and I use it as
well. Still, I agree that there is no need to add an extra mechanism
with PGOPTIONS if a feature already exists. One thing which is also
--temp-config is only supported in temp-instance mode which I wanted to avoid
But if you think that this feature is supported enough by this I agree it doesn’t make sense
to add something. I just don’t see any disadvantage in my approach.
Manuel
On 5/29/18 09:19, Manuel Kniep wrote:
Consider something like this in an extensions makefile:
ifeq ($(shell test $(VERSION_NUM) -ge 90600; echo $$?),0)
PGOPTIONS+= "--max_parallel_workers_per_gather=0"
endif
I think you can probably write this inside your test .sql file using a
bit of PL/pgSQL.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services