14th September 2023: PostgreSQL 16 Released!
Unsupported versions: 7.0 / 6.5 / 6.4
This documentation is for an unsupported version of PostgreSQL.
You may want to view the same page for the current version, or one of the other supported versions listed above instead.

Chapter 34. Regression Test

Regression test instructions and analysis.

The PostgreSQL regression tests are a comprehensive set of tests for the SQL implementation embedded in PostgreSQL. They test standard SQL operations as well as the extended capabilities of PostgreSQL.

There are two different ways in which the regression tests can be run: the "sequential" method and the "parallel" method. The sequential method runs each test script in turn, whereas the parallel method starts up multiple server processes to run groups of tests in parallel. Parallel testing gives confidence that interprocess communication and locking are working correctly. Another key difference is that the sequential test procedure uses an already-installed postmaster, whereas the parallel test procedure tests a system that has been built but not yet installed. (The parallel test script actually does an installation into a temporary directory and fires up a private postmaster therein.)

Some properly installed and fully functional PostgreSQL installations can "fail" some of these regression tests due to artifacts of floating point representation and time zone support. The tests are currently evaluated using a simple diff comparison against the outputs generated on a reference system, so the results are sensitive to small system differences. When a test is reported as "failed", always examine the differences between expected and actual results; you may well find that the differences are not significant.

The regression tests were originally developed by Jolly Chen and Andrew Yu, and were extensively revised/repackaged by Marc Fournier and Thomas Lockhart. From PostgreSQL v6.1 onward the regression tests are current for every official release.

Regression Environment

The regression testing notes below assume the following (except where noted):

  • Commands are Unix-compatible. See note below.

  • Defaults are used except where noted.

  • User postgres is the Postgres superuser.

  • The source path is /usr/src/pgsql (other paths are possible).

  • The runtime path is /usr/local/pgsql (other paths are possible).

Normally, the regression tests should be run as the postgres user since the 'src/test/regress' directory and sub-directories are owned by the postgres user. If you run the regression test as another user the 'src/test/regress' directory tree must be writeable by that user.

It was formerly necessary to run the postmaster with system time zone set to PST, but this is no longer required. You can run the regression tests under your normal postmaster configuration. The test script will set the PGTZ environment variable to ensure that timezone-dependent tests produce the expected results. However, your system must provide library support for the PST8PDT time zone, or the timezone-dependent tests will fail. To verify that your machine does have this support, type the following:

setenv TZ PST8PDT

The "date" command above should have returned the current system time in the PST8PDT time zone. If the PST8PDT database is not available, then your system may have returned the time in GMT. If the PST8PDT time zone is not available, you can set the time zone rules explicitly:

setenv PGTZ PST8PDT7,M04.01.0,M10.05.03

The directory layout for the regression test area is:

Table 34-1. Directory Layout

Directory Description
Directory Description
input Source files that are converted using make all into some of the .sql files in the sql subdirectory.
output Source files that are converted using make all into .out files in the expected subdirectory.
sql .sql files used to perform the regression tests.
expected .out files that represent what we expect the results to look like.
results .out files that contain what the results actually look like. Also used as temporary storage for table copy testing.
tmp_check Temporary installation created by parallel testing script.