Thread: [HACKERS] check with serial
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
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Attachment
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
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
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