1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Chapter27.Regression Tests</title>
<link rel="stylesheet" href="stylesheet.css" type="text/css">
<link rev="made" href="pgsql-docs@postgresql.org">
<meta name="generator" content="DocBook XSL Stylesheets V1.70.0">
<link rel="start" href="index.html" title="PostgreSQL 8.1.4 Documentation">
<link rel="up" href="admin.html" title="PartIII.Server Administration">
<link rel="prev" href="wal-internals.html" title="26.4.WAL Internals">
<link rel="next" href="regress-evaluation.html" title="27.2.Test Evaluation">
<link rel="copyright" href="ln-legalnotice.html" title="Legal Notice">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="chapter" lang="en" id="regress">
<div class="titlepage"><div><div><h2 class="title">
<a name="regress"></a>Chapter27.Regression Tests</h2></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt><span class="sect1"><a href="regress.html#regress-run">27.1. Running the Tests</a></span></dt>
<dt><span class="sect1"><a href="regress-evaluation.html">27.2. Test Evaluation</a></span></dt>
<dd><dl>
<dt><span class="sect2"><a href="regress-evaluation.html#id674902">27.2.1. Error message differences</a></span></dt>
<dt><span class="sect2"><a href="regress-evaluation.html#id674925">27.2.2. Locale differences</a></span></dt>
<dt><span class="sect2"><a href="regress-evaluation.html#id674939">27.2.3. Date and time differences</a></span></dt>
<dt><span class="sect2"><a href="regress-evaluation.html#id674969">27.2.4. Floating-point differences</a></span></dt>
<dt><span class="sect2"><a href="regress-evaluation.html#id675046">27.2.5. Row ordering differences</a></span></dt>
<dt><span class="sect2"><a href="regress-evaluation.html#id675124">27.2.6. Insufficient stack depth</a></span></dt>
<dt><span class="sect2"><a href="regress-evaluation.html#id675168">27.2.7. The “<span class="quote">random</span>” test</a></span></dt>
</dl></dd>
<dt><span class="sect1"><a href="regress-variant.html">27.3. Variant Comparison Files</a></span></dt>
</dl>
</div>
<a name="id674371"></a><a name="id674381"></a><p> The regression tests are a comprehensive set of tests for the SQL
implementation in <span class="productname">PostgreSQL</span>. They test
standard SQL operations as well as the extended capabilities of
<span class="productname">PostgreSQL</span>.
</p>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="regress-run"></a>27.1.Running the Tests</h2></div></div></div>
<p> The regression tests can be run against an already installed and
running server, or using a temporary installation within the build
tree. Furthermore, there is a “<span class="quote">parallel</span>” and a
“<span class="quote">sequential</span>” mode for running the tests. 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. For
historical reasons, the sequential test is usually run against an
existing installation and the parallel method against a temporary
installation, but there are no technical reasons for this.
</p>
<p> To run the regression tests after building but before installation,
type
</p>
<pre class="screen">gmake check</pre>
<p>
in the top-level directory. (Or you can change to
<code class="filename">src/test/regress</code> and run the command there.)
This will first build several auxiliary files, such as
some sample user-defined trigger functions, and then run the test driver
script. At the end you should see something like
</p>
<pre class="screen"><code class="computeroutput">======================
All 98 tests passed.
======================</code></pre>
<p>
or otherwise a note about which tests failed. See <a href="regress-evaluation.html" title="27.2.Test Evaluation">Section27.2, “Test Evaluation”</a> below before assuming that a
“<span class="quote">failure</span>” represents a serious problem.
</p>
<p> Because this test method runs a temporary server, it will not work
when you are the root user (since the server will not start as root).
If you already did the build as root, you do not have to start all
over. Instead, make the regression test directory writable by
some other user, log in as that user, and restart the tests.
For example
</p>
<pre class="screen"><code class="prompt">root# </code><strong class="userinput"><code>chmod -R a+w src/test/regress</code></strong>
<code class="prompt">root# </code><strong class="userinput"><code>chmod -R a+w contrib/spi</code></strong>
<code class="prompt">root# </code><strong class="userinput"><code>su - joeuser</code></strong>
<code class="prompt">joeuser$ </code><strong class="userinput"><code>cd <em class="replaceable"><code>top-level build directory</code></em></code></strong>
<code class="prompt">joeuser$ </code><strong class="userinput"><code>gmake check</code></strong></pre>
<p>
(The only possible “<span class="quote">security risk</span>” here is that other
users might be able to alter the regression test results behind
your back. Use common sense when managing user permissions.)
</p>
<p> Alternatively, run the tests after installation.
</p>
<p> If you have configured <span class="productname">PostgreSQL</span> to install
into a location where an older <span class="productname">PostgreSQL</span>
installation already exists, and you perform <code class="literal">gmake check</code>
before installing the new version, you may find that the tests fail
because the new programs try to use the already-installed shared
libraries. (Typical symptoms are complaints about undefined symbols.)
If you wish to run the tests before overwriting the old installation,
you'll need to build with <code class="literal">configure --disable-rpath</code>.
It is not recommended that you use this option for the final installation,
however.
</p>
<p> The parallel regression test starts quite a few processes under your
user ID. Presently, the maximum concurrency is twenty parallel test
scripts, which means sixty processes: there's a server process, a
<span class="application">psql</span>, and usually a shell parent process for the
<span class="application">psql</span> for each test script.
So if your system enforces a per-user limit on the number of processes,
make sure this limit is at least seventy-five or so, else you may get
random-seeming failures in the parallel test. If you are not in
a position to raise the limit, you can cut down the degree of parallelism
by setting the <code class="literal">MAX_CONNECTIONS</code> parameter. For example,
</p>
<pre class="screen">gmake MAX_CONNECTIONS=10 check</pre>
<p>
runs no more than ten tests concurrently.
</p>
<p> On some systems, the default Bourne-compatible shell
(<code class="filename">/bin/sh</code>) gets confused when it has to manage
too many child processes in parallel. This may cause the parallel
test run to lock up or fail. In such cases, specify a different
Bourne-compatible shell on the command line, for example:
</p>
<pre class="screen">gmake SHELL=/bin/ksh check</pre>
<p>
If no non-broken shell is available, you may be able to work around the
problem by limiting the number of connections, as shown above.
</p>
<p> To run the tests after installation (see <a href="installation.html" title="Chapter14. Installation Instructions">Chapter14, <i> Installation Instructions</i></a>),
initialize a data area and start the
server, as explained in <a href="runtime.html" title="Chapter16.Operating System Environment">Chapter16, <i>Operating System Environment</i></a>, then type
</p>
<pre class="screen">gmake installcheck</pre>
<p>
or for a parallel test
</p>
<pre class="screen">gmake installcheck-parallel</pre>
<p>
The tests will expect to contact the server at the local host and the
default port number, unless directed otherwise by <code class="envar">PGHOST</code> and
<code class="envar">PGPORT</code> environment variables.
</p>
<p> The source distribution also contains regression tests for the optional
procedural languages and for some of the <code class="filename">contrib</code> modules.
At present, these tests can be used only against an already-installed
server. To run the tests for all procedural languages that have been
built and installed, change to the <code class="filename">src/pl</code> directory of the
build tree and type
</p>
<pre class="screen">gmake installcheck</pre>
<p>
You can also do this in any of the subdirectories of <code class="filename">src/pl</code>
to run tests for just one procedural language. To run the tests for all
<code class="filename">contrib</code> modules that have them, change to the
<code class="filename">contrib</code> directory of the build tree and type
</p>
<pre class="screen">gmake installcheck</pre>
<p>
The <code class="filename">contrib</code> modules must have been built and installed first.
You can also do this in a subdirectory of <code class="filename">contrib</code> to run
the tests for just one module.
</p>
</div>
</div></body>
</html>
|
