Re: [HACKERS] separate serial_schedule useful?

I wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> There's no reason why pg_regress couldn't have a
>> --bail-if-group-size-exceeds=N argument, or why we couldn't have a
>> separate Perl script to validate the schedule file as part of the
>> build process.

> I'd go for the former approach; seems like less new code and fewer cycles
> used to enforce the rule.

Concretely, how about the attached?  (Obviously we'd have to fix
parallel_schedule before committing this.)

            regards, tom lane

diff --git a/src/test/regress/GNUmakefile b/src/test/regress/GNUmakefile
index b923ea1..56cd202 100644
*** a/src/test/regress/GNUmakefile
--- b/src/test/regress/GNUmakefile
*************** tablespace-setup:
*** 124,130 ****
  ## Run tests
  ##

! REGRESS_OPTS = --dlpath=. $(EXTRA_REGRESS_OPTS)

  check: all tablespace-setup
      $(pg_regress_check) $(REGRESS_OPTS) --schedule=$(srcdir)/parallel_schedule $(MAXCONNOPT) $(EXTRA_TESTS)
--- 124,130 ----
  ## Run tests
  ##

! REGRESS_OPTS = --dlpath=. --max-concurrent-tests=20 $(EXTRA_REGRESS_OPTS)

  check: all tablespace-setup
      $(pg_regress_check) $(REGRESS_OPTS) --schedule=$(srcdir)/parallel_schedule $(MAXCONNOPT) $(EXTRA_TESTS)
diff --git a/src/test/regress/pg_regress.c b/src/test/regress/pg_regress.c
index abb742b..ff979b8 100644
*** a/src/test/regress/pg_regress.c
--- b/src/test/regress/pg_regress.c
*************** char       *launcher = NULL;
*** 78,83 ****
--- 78,84 ----
  static _stringlist *loadlanguage = NULL;
  static _stringlist *loadextension = NULL;
  static int    max_connections = 0;
+ static int    max_concurrent_tests = 0;
  static char *encoding = NULL;
  static _stringlist *schedulelist = NULL;
  static _stringlist *extra_tests = NULL;
*************** run_schedule(const char *schedule, test_
*** 1691,1696 ****
--- 1692,1704 ----
              wait_for_tests(pids, statuses, NULL, 1);
              /* status line is finished below */
          }
+         else if (max_concurrent_tests > 0 && max_concurrent_tests < num_tests)
+         {
+             /* can't print scbuf here, it's already been trashed */
+             fprintf(stderr, _("too many tests (more than %d) in schedule file \"%s\" line %d\n"),
+                     max_concurrent_tests, schedule, line_num);
+             exit(2);
+         }
          else if (max_connections > 0 && max_connections < num_tests)
          {
              int            oldest = 0;
*************** help(void)
*** 1999,2004 ****
--- 2007,2014 ----
      printf(_("                            tests; can appear multiple times\n"));
      printf(_("  --max-connections=N       maximum number of concurrent connections\n"));
      printf(_("                            (default is 0, meaning unlimited)\n"));
+     printf(_("  --max-concurrent-tests=N  maximum number of concurrent tests in schedule\n"));
+     printf(_("                            (default is 0, meaning unlimited)\n"));
      printf(_("  --outputdir=DIR           place output files in DIR (default \".\")\n"));
      printf(_("  --schedule=FILE           use test ordering schedule from FILE\n"));
      printf(_("                            (can be used multiple times to concatenate)\n"));
*************** regression_main(int argc, char *argv[],
*** 2048,2053 ****
--- 2058,2064 ----
          {"launcher", required_argument, NULL, 21},
          {"load-extension", required_argument, NULL, 22},
          {"config-auth", required_argument, NULL, 24},
+         {"max-concurrent-tests", required_argument, NULL, 25},
          {NULL, 0, NULL, 0}
      };

*************** regression_main(int argc, char *argv[],
*** 2161,2166 ****
--- 2172,2180 ----
              case 24:
                  config_auth_datadir = pg_strdup(optarg);
                  break;
+             case 25:
+                 max_concurrent_tests = atoi(optarg);
+                 break;
              default:
                  /* getopt_long already emitted a complaint */
                  fprintf(stderr, _("\nTry \"%s -h\" for more information.\n"),

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers