begriffs open source - ai-pg/blob - full-docs/txt/regress-run.txt

   1
   2 31.1. Running the Tests #
   3
   4    31.1.1. Running the Tests Against a Temporary Installation
   5    31.1.2. Running the Tests Against an Existing Installation
   6    31.1.3. Additional Test Suites
   7    31.1.4. Locale and Encoding
   8    31.1.5. Custom Server Settings
   9    31.1.6. Extra Tests
  10
  11    The regression tests can be run against an already installed and
  12    running server, or using a temporary installation within the build
  13    tree. Furthermore, there is a “parallel” and a “sequential” mode for
  14    running the tests. The sequential method runs each test script alone,
  15    while the parallel method starts up multiple server processes to run
  16    groups of tests in parallel. Parallel testing adds confidence that
  17    interprocess communication and locking are working correctly. Some
  18    tests may run sequentially even in the “parallel” mode in case this is
  19    required by the test.
  20
  21 31.1.1. Running the Tests Against a Temporary Installation #
  22
  23    To run the parallel regression tests after building but before
  24    installation, type:
  25 make check
  26
  27    in the top-level directory. (Or you can change to src/test/regress and
  28    run the command there.) Tests which are run in parallel are prefixed
  29    with “+”, and tests which run sequentially are prefixed with “-”. At
  30    the end you should see something like:
  31
  32 # All 213 tests passed.
  33
  34
  35    or otherwise a note about which tests failed. See Section 31.2 below
  36    before assuming that a “failure” represents a serious problem.
  37
  38    Because this test method runs a temporary server, it will not work if
  39    you did the build as the root user, since the server will not start as
  40    root. Recommended procedure is not to do the build as root, or else to
  41    perform testing after completing the installation.
  42
  43    If you have configured PostgreSQL to install into a location where an
  44    older PostgreSQL installation already exists, and you perform make
  45    check before installing the new version, you might find that the tests
  46    fail because the new programs try to use the already-installed shared
  47    libraries. (Typical symptoms are complaints about undefined symbols.)
  48    If you wish to run the tests before overwriting the old installation,
  49    you'll need to build with configure --disable-rpath. It is not
  50    recommended that you use this option for the final installation,
  51    however.
  52
  53    The parallel regression test starts quite a few processes under your
  54    user ID. Presently, the maximum concurrency is twenty parallel test
  55    scripts, which means forty processes: there's a server process and a
  56    psql process for each test script. So if your system enforces a
  57    per-user limit on the number of processes, make sure this limit is at
  58    least fifty or so, else you might get random-seeming failures in the
  59    parallel test. If you are not in a position to raise the limit, you can
  60    cut down the degree of parallelism by setting the MAX_CONNECTIONS
  61    parameter. For example:
  62 make MAX_CONNECTIONS=10 check
  63
  64    runs no more than ten tests concurrently.
  65
  66 31.1.2. Running the Tests Against an Existing Installation #
  67
  68    To run the tests after installation (see Chapter 17), initialize a data
  69    directory and start the server as explained in Chapter 18, then type:
  70 make installcheck
  71
  72    or for a parallel test:
  73 make installcheck-parallel
  74
  75    The tests will expect to contact the server at the local host and the
  76    default port number, unless directed otherwise by PGHOST and PGPORT
  77    environment variables. The tests will be run in a database named
  78    regression; any existing database by this name will be dropped.
  79
  80    The tests will also transiently create some cluster-wide objects, such
  81    as roles, tablespaces, and subscriptions. These objects will have names
  82    beginning with regress_. Beware of using installcheck mode with an
  83    installation that has any actual global objects named that way.
  84
  85 31.1.3. Additional Test Suites #
  86
  87    The make check and make installcheck commands run only the “core”
  88    regression tests, which test built-in functionality of the PostgreSQL
  89    server. The source distribution contains many additional test suites,
  90    most of them having to do with add-on functionality such as optional
  91    procedural languages.
  92
  93    To run all test suites applicable to the modules that have been
  94    selected to be built, including the core tests, type one of these
  95    commands at the top of the build tree:
  96 make check-world
  97 make installcheck-world
  98
  99    These commands run the tests using temporary servers or an
 100    already-installed server, respectively, just as previously explained
 101    for make check and make installcheck. Other considerations are the same
 102    as previously explained for each method. Note that make check-world
 103    builds a separate instance (temporary data directory) for each tested
 104    module, so it requires more time and disk space than make
 105    installcheck-world.
 106
 107    On a modern machine with multiple CPU cores and no tight
 108    operating-system limits, you can make things go substantially faster
 109    with parallelism. The recipe that most PostgreSQL developers actually
 110    use for running all tests is something like
 111 make check-world -j8 >/dev/null
 112
 113    with a -j limit near to or a bit more than the number of available
 114    cores. Discarding stdout eliminates chatter that's not interesting when
 115    you just want to verify success. (In case of failure, the stderr
 116    messages are usually enough to determine where to look closer.)
 117
 118    Alternatively, you can run individual test suites by typing make check
 119    or make installcheck in the appropriate subdirectory of the build tree.
 120    Keep in mind that make installcheck assumes you've installed the
 121    relevant module(s), not only the core server.
 122
 123    The additional tests that can be invoked this way include:
 124      * Regression tests for optional procedural languages. These are
 125        located under src/pl.
 126      * Regression tests for contrib modules, located under contrib. Not
 127        all contrib modules have tests.
 128      * Regression tests for the interface libraries, located in
 129        src/interfaces/libpq/test and src/interfaces/ecpg/test.
 130      * Tests for core-supported authentication methods, located in
 131        src/test/authentication. (See below for additional
 132        authentication-related tests.)
 133      * Tests stressing behavior of concurrent sessions, located in
 134        src/test/isolation.
 135      * Tests for crash recovery and physical replication, located in
 136        src/test/recovery.
 137      * Tests for logical replication, located in src/test/subscription.
 138      * Tests of client programs, located under src/bin.
 139
 140    When using installcheck mode, these tests will create and destroy test
 141    databases whose names include regression, for example pl_regression or
 142    contrib_regression. Beware of using installcheck mode with an
 143    installation that has any non-test databases named that way.
 144
 145    Some of these auxiliary test suites use the TAP infrastructure
 146    explained in Section 31.4. The TAP-based tests are run only when
 147    PostgreSQL was configured with the option --enable-tap-tests. This is
 148    recommended for development, but can be omitted if there is no suitable
 149    Perl installation.
 150
 151    Some test suites are not run by default, either because they are not
 152    secure to run on a multiuser system, because they require special
 153    software or because they are resource intensive. You can decide which
 154    test suites to run additionally by setting the make or environment
 155    variable PG_TEST_EXTRA to a whitespace-separated list, for example:
 156 make check-world PG_TEST_EXTRA='kerberos ldap ssl load_balance libpq_encryption'
 157
 158    The following values are currently supported:
 159
 160    kerberos
 161           Runs the test suite under src/test/kerberos. This requires an
 162           MIT Kerberos installation and opens TCP/IP listen sockets.
 163
 164    ldap
 165           Runs the test suite under src/test/ldap. This requires an
 166           OpenLDAP installation and opens TCP/IP listen sockets.
 167
 168    libpq_encryption
 169           Runs the test
 170           src/interfaces/libpq/t/005_negotiate_encryption.pl. This opens
 171           TCP/IP listen sockets. If PG_TEST_EXTRA also includes kerberos,
 172           additional tests that require an MIT Kerberos installation are
 173           enabled.
 174
 175    load_balance
 176           Runs the test src/interfaces/libpq/t/004_load_balance_dns.pl.
 177           This requires editing the system hosts file and opens TCP/IP
 178           listen sockets.
 179
 180    oauth
 181           Runs the test suite under src/test/modules/oauth_validator. This
 182           opens TCP/IP listen sockets for a test server running HTTPS.
 183
 184    regress_dump_restore
 185           Runs an additional test suite in
 186           src/bin/pg_upgrade/t/002_pg_upgrade.pl which cycles the
 187           regression database through pg_dump/ pg_restore. Not enabled by
 188           default because it is resource intensive.
 189
 190    sepgsql
 191           Runs the test suite under contrib/sepgsql. This requires an
 192           SELinux environment that is set up in a specific way; see
 193           Section F.40.3.
 194
 195    ssl
 196           Runs the test suite under src/test/ssl. This opens TCP/IP listen
 197           sockets.
 198
 199    wal_consistency_checking
 200           Uses wal_consistency_checking=all while running certain tests
 201           under src/test/recovery. Not enabled by default because it is
 202           resource intensive.
 203
 204    xid_wraparound
 205           Runs the test suite under src/test/modules/xid_wraparound. Not
 206           enabled by default because it is resource intensive.
 207
 208    Tests for features that are not supported by the current build
 209    configuration are not run even if they are mentioned in PG_TEST_EXTRA.
 210
 211    In addition, there are tests in src/test/modules which will be run by
 212    make check-world but not by make installcheck-world. This is because
 213    they install non-production extensions or have other side-effects that
 214    are considered undesirable for a production installation. You can use
 215    make install and make installcheck in one of those subdirectories if
 216    you wish, but it's not recommended to do so with a non-test server.
 217
 218 31.1.4. Locale and Encoding #
 219
 220    By default, tests using a temporary installation use the locale defined
 221    in the current environment and the corresponding database encoding as
 222    determined by initdb. It can be useful to test different locales by
 223    setting the appropriate environment variables, for example:
 224 make check LANG=C
 225 make check LC_COLLATE=en_US.utf8 LC_CTYPE=fr_CA.utf8
 226
 227    For implementation reasons, setting LC_ALL does not work for this
 228    purpose; all the other locale-related environment variables do work.
 229
 230    When testing against an existing installation, the locale is determined
 231    by the existing database cluster and cannot be set separately for the
 232    test run.
 233
 234    You can also choose the database encoding explicitly by setting the
 235    variable ENCODING, for example:
 236 make check LANG=C ENCODING=EUC_JP
 237
 238    Setting the database encoding this way typically only makes sense if
 239    the locale is C; otherwise the encoding is chosen automatically from
 240    the locale, and specifying an encoding that does not match the locale
 241    will result in an error.
 242
 243    The database encoding can be set for tests against either a temporary
 244    or an existing installation, though in the latter case it must be
 245    compatible with the installation's locale.
 246
 247 31.1.5. Custom Server Settings #
 248
 249    There are several ways to use custom server settings when running a
 250    test suite. This can be useful to enable additional logging, adjust
 251    resource limits, or enable extra run-time checks such as
 252    debug_discard_caches. But note that not all tests can be expected to
 253    pass cleanly with arbitrary settings.
 254
 255    Extra options can be passed to the various initdb commands that are run
 256    internally during test setup using the environment variable
 257    PG_TEST_INITDB_EXTRA_OPTS. For example, to run a test with checksums
 258    enabled and a custom WAL segment size and work_mem setting, use:
 259 make check PG_TEST_INITDB_EXTRA_OPTS='-k --wal-segsize=4 -c work_mem=50MB'
 260
 261    For the core regression test suite and other tests driven by
 262    pg_regress, custom run-time server settings can also be set in the
 263    PGOPTIONS environment variable (for settings that allow this), for
 264    example:
 265 make check PGOPTIONS="-c debug_parallel_query=regress -c work_mem=50MB"
 266
 267    (This makes use of functionality provided by libpq; see options for
 268    details.)
 269
 270    When running against a temporary installation, custom settings can also
 271    be set by supplying a pre-written postgresql.conf:
 272 echo 'log_checkpoints = on' > test_postgresql.conf
 273 echo 'work_mem = 50MB' >> test_postgresql.conf
 274 make check EXTRA_REGRESS_OPTS="--temp-config=test_postgresql.conf"
 275
 276 31.1.6. Extra Tests #
 277
 278    The core regression test suite contains a few test files that are not
 279    run by default, because they might be platform-dependent or take a very
 280    long time to run. You can run these or other extra test files by
 281    setting the variable EXTRA_TESTS. For example, to run the numeric_big
 282    test:
 283 make check EXTRA_TESTS=numeric_big