A little enhancement for hashdisk testset
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:t42982psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 08:09 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 t42982_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 t42982_1 && git checkout t42982_1Patchset v1 (message #1) is on t42982_1
Hi,
In (src/test/regress/sql/aggregates.sql)
I found some tables is not dropped at the end of the sqlscript,
It does not hava any problem, but I think it's better to drop the table in time.
Please see the attachment for the patch.
Best regards,
Houzj
On 24 Sep 2020, at 07:45, Hou, Zhijie <houzj.fnst@cn.fujitsu.com> wrote:
I found some tables is not dropped at the end of the sqlscript,
It does not hava any problem, but I think it's better to drop the table in time.
There is value in keeping a representative set of objects around after
regression tests, as the database which is left after regression tests run is
used as the input to the pg_regress tests. That being said, I don't think that
was the intention for these relationns in commit 92c58fd94801, but in general
we should avoid cleaning up too much to ensure that we stress pg_upgrade well
enough (there is a delicate balance to keep test runtime short as well of
course).
cheers ./daniel