check with serial
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:t36610psql -h localhost -U postgresBuilt from patchset v2 (message #2), July 28, 2026 at 06:52 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 t36610_2 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 t36610_2 && git checkout t36610_2Patchset v2 (message #2) is on t36610_2
The other day I wanted to run "make check" but with the serial schedule.
This wasn't as easy as it should have been. Although we now have
installcheck-parallel we don't have check-serial. Should we have that?
Alternatively, should we allow a SCHEDULE=foo argument for the "check"
target which defaults to parallel?
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 05/01/2017 09:39 AM, Andrew Dunstan wrote:
The other day I wanted to run "make check" but with the serial schedule.
This wasn't as easy as it should have been. Although we now have
installcheck-parallel we don't have check-serial. Should we have that?
Alternatively, should we allow a SCHEDULE=foo argument for the "check"
target which defaults to parallel?
Here's a simple patch that does what I had in mind. It allows providing
for an arbitrary schedule file in both the check and installcheck
recipes. The historic behaviour is preserved.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Tue, May 2, 2017 at 11:30 PM, Andrew Dunstan <
andrew.dunstan@2ndquadrant.com> wrote:
Here's a simple patch that does what I had in mind. It allows providing
for an arbitrary schedule file in both the check and installcheck
recipes. The historic behaviour is preserved.
Hmm, installcheck command with SCHEDULE set as "Parallel" does not honor
"MAXCONNOPT" settings in the attached patch.
And, now after your patch, do we still need "installcheck-parallel"
command? It is redundant IMO, just give a thought.
Documentation changes("Running the Tests") are also required as the
behavior documented is now changed in this patch.
Best Regards,
Vaishnavi,
Fujitsu Australia.
On 05/02/2017 10:13 PM, Vaishnavi Prabakaran wrote:
On Tue, May 2, 2017 at 11:30 PM, Andrew Dunstan
<andrew.dunstan@2ndquadrant.com
<mailto:andrew.dunstan@2ndquadrant.com>> wrote:Here's a simple patch that does what I had in mind. It allows
providing
for an arbitrary schedule file in both the check and installcheck
recipes. The historic behaviour is preserved.Hmm, installcheck command with SCHEDULE set as "Parallel" does not
honor "MAXCONNOPT" settings in the attached patch.
good point.
And, now after your patch, do we still need "installcheck-parallel"
command? It is redundant IMO, just give a thought.
I'd be quite happy to remove the target in favor of this more general
solution.
Thoughts?
Documentation changes("Running the Tests") are also required as the
behavior documented is now changed in this patch.
Yes, agreed. Thanks for your comments.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
On 05/02/2017 10:13 PM, Vaishnavi Prabakaran wrote:
And, now after your patch, do we still need "installcheck-parallel"
command? It is redundant IMO, just give a thought.
I'd be quite happy to remove the target in favor of this more general
solution.
-1 --- that will break a lot of existing habits to no purpose, not to
mention creating complications for scripts used to test multiple branches.
We have intentionally maintained backwards compatibility in these testing
targets for a very long time, even though that's left us with
inconsistencies like installcheck defaulting to serial while check
defaults to parallel. Adding a new capability is not an excuse for
breaking the historical test targets.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 05/03/2017 10:12 AM, Tom Lane wrote:
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
On 05/02/2017 10:13 PM, Vaishnavi Prabakaran wrote:
And, now after your patch, do we still need "installcheck-parallel"
command? It is redundant IMO, just give a thought.I'd be quite happy to remove the target in favor of this more general
solution.-1 --- that will break a lot of existing habits to no purpose, not to
mention creating complications for scripts used to test multiple branches.
We have intentionally maintained backwards compatibility in these testing
targets for a very long time, even though that's left us with
inconsistencies like installcheck defaulting to serial while check
defaults to parallel. Adding a new capability is not an excuse for
breaking the historical test targets.
OK
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers