PgSQL · 最佳实践 · 回归测试探寻

make check          #  parallel running the Tests Against a Temporary Installation 
make installcheck            # serial running the Tests Against an Existing Installation 
make installcheck-paralle   # parallel  running the Tests Against an Existing Installation

Documentation concerning how to run these regression tests and interpret the 
results can be found in the PostgreSQL manual, in the chapter "Regression Tests".

pg_regress --inputdir=. --bindir='tmp_basedir_polardb_pg_1100_bld/bin'  
--dlpath=. --max-concurrent-tests=20 --user=regress  --schedule=./serial_schedule

./pg_regress -h
####################################\
PostgreSQL regression test driver

Usage:
  pg_regress [OPTION]... [EXTRA-TEST]...

Options:
      --bindir=BINPATH          use BINPATH for programs that are run;
                                if empty, use PATH from the environment
      --config-auth=DATADIR     update authentication settings for DATADIR
      --create-role=ROLE        create the specified role before testing
      --dbname=DB               use database DB (default "regression")
      --debug                   turn on debug mode in programs that are run
      --dlpath=DIR              look for dynamic libraries in DIR
      --encoding=ENCODING       use ENCODING as the encoding
  -h, --help                    show this help, then exit
      --inputdir=DIR            take input files from DIR (default ".")
      --launcher=CMD            use CMD as launcher of psql
      --load-extension=EXT      load the named extension before running the
                                tests; can appear multiple times
      --load-language=LANG      load the named language before running the
                                tests; can appear multiple times
      --max-connections=N       maximum number of concurrent connections
                                (default is 0, meaning unlimited)
      --max-concurrent-tests=N  maximum number of concurrent tests in schedule
                                (default is 0, meaning unlimited)
      --outputdir=DIR           place output files in DIR (default ".")
      --schedule=FILE           use test ordering schedule from FILE
                                (can be used multiple times to concatenate)
      --temp-instance=DIR       create a temporary instance in DIR
      --use-existing            use an existing installation
      --no-restrict-auth        disable restricted authentication settings
  -V, --version                 output version information, then exit

Options for "temp-instance" mode:
      --no-locale               use C locale
      --port=PORT               start postmaster on PORT
      --temp-config=FILE        append contents of FILE to temporary config
      --temp-initdb-opts=OPTS   additional flags passed to initdb

Options for using an existing installation:
      --host=HOST               use postmaster running on HOST
      --port=PORT               use postmaster running at PORT
      --user=USER               connect as USER

The exit status is 0 if all tests passed, 1 if some tests failed, and 2
if the tests could not be run for some reason.

Report bugs to <support@enterprisedb.com>.

int
main(int argc, char *argv[])
{
  return regression_main(argc, argv, psql_init, psql_start_test);
}

test: tablespace
test: boolean
test: char
test: name
test: varchar
test: text   
......

# ----------
# The first group of parallel tests
# ----------
test: boolean char name varchar text int2 int4 int8 oid float4 float8 bit numeric txid uuid enum money rangetypes pg_lsn regproc
......

该目录包含一组针对并发行为的PostgreSQL的的测试。这些测试需要运行多个交互事务，
这需要管理多个并发连接，因此无法使用正常的pg_regress程序进行测试。
名字“隔离”来自这个事实，原来的动机是测试可序列化隔离级别;
但测试其他类型的并发行为也被添加了。

setup { <SQL> }

  The given SQL block is executed once, in one session only, before running
  the test.  Create any test tables or other required objects here.  This
  part is optional.  Multiple setup blocks are allowed if needed; each is
  run separately, in the given order.  (The reason for allowing multiple
  setup blocks is that each block is run as a single PQexec submission,
  and some statements such as VACUUM cannot be combined with others in such
  a block.)

teardown { <SQL> }

  The teardown SQL block is executed once after the test is finished. Use
  this to clean up in preparation for the next permutation, e.g dropping
  any test tables created by setup. This part is optional.

session "<name>"

  There are normally several "session" parts in a spec file. Each
  session is executed in its own connection. A session part consists
  of three parts: setup, teardown and one or more "steps". The per-session
  setup and teardown parts have the same syntax as the per-test setup and
  teardown described above, but they are executed in each session. The
  setup part typically contains a "BEGIN" command to begin a transaction.

  Each step has the syntax

  step "<name>" { <SQL> }

  where <name> is a name identifying this step, and SQL is a SQL statement
  (or statements, separated by semicolons) that is executed in the step.
  Step names must be unique across the whole spec file.

permutation "<step name>" ...

  A permutation line specifies a list of steps that are run in that order.
  Any number of permutation lines can appear.  If no permutation lines are
  given, the test program automatically generates all possible orderings
  of the steps from each session (running the steps of any one session in
  order).  Note that the list of steps in a manually specified
  "permutation" line doesn't actually have to be a permutation of the
  available steps; it could for instance repeat some steps more than once,
  or leave others out.

int
main(int argc, char *argv[])
{
  return regression_main(argc, argv, isolation_init, isolation_start_test);
}