What you will learn
Build a PostgreSQL 17 lab and check library dependencies, ICU choices, and the executable actually selected by PATH. The old 17.4 label is historical. The example uses the Autoconf/Make build on Linux. Select a maintained patch release within the chosen major version and inspect its release notes.
Before you begin
Install the release’s compiler, build tools, OpenSSL development headers, and chosen locale-library dependencies through your OS package manager. Download and verify the official source archive. Use a dedicated non-root database service account. The lab directory must be new and empty; do not run initdb on an existing cluster.
1. Configure and compile the verified source
./configure --prefix=/opt/postgresql/17 --with-openssl
make -j2
make check
make install
Run these inside the extracted source tree. Provision a writable installation prefix or install through your administrator’s packaging procedure. Resolve missing libraries explicitly; removing build features merely to silence configure can change required behavior.
2. Check which binaries you are using
/opt/postgresql/17/bin/pg_config --configure
/opt/postgresql/17/bin/psql --version
/opt/postgresql/17/bin/postgres --version
Use full paths during the first test. A successful build does not replace an older psql earlier in PATH. For the TLS-client exercise, this check is useful even if the database server is hosted elsewhere.
3. Initialize a separate local lab cluster
/opt/postgresql/17/bin/initdb -D /srv/postgresql/tutorial-data --auth-local=peer --auth-host=scram-sha-256
/opt/postgresql/17/bin/pg_ctl -D /srv/postgresql/tutorial-data -l /srv/postgresql/tutorial.log start
Run as the database service account, with the directory owned by it. Confirm the default port is free. Configure a password interactively with psql’s \password if host authentication is needed; do not put a real password in shell history.
4. Separate TLS capability from TLS configuration
A build with OpenSSL can use TLS, but the server also needs certificates, keys, ssl=on, and appropriate pg_hba.conf rules. For a remote server with TLS already configured, test name and certificate validation:
/opt/postgresql/17/bin/psql "host=host1.sample.com dbname=tutorial user=app_reader sslmode=verify-full sslrootcert=/secure/ca.crt"
Use a protected password file or interactive prompt. The certificate must match the host name; encryption without identity verification is a different security property.
Example output
The following is an illustrative, normalized lab result, not output captured from a live customer system. Your versions, addresses, timings, and row counts will differ.
-- After connecting through the configured TLS endpoint
SELECT ssl FROM pg_stat_ssl WHERE pid = pg_backend_pid();
ssl
-----
t
(1 row)
Run the SELECT on the TLS connection you are checking. A true value confirms encryption for this session; certificate and hostname validation are established by the client’s verify-full settings. A local Unix-socket session may report false and is not a test of remote TLS.
Verify the result
Run SELECT version(); and \conninfo in psql. On the server, inspect pg_stat_ssl for the current backend when testing TLS. Confirm the software prefix and data_directory match the intended lab, then execute a simple create/insert/select transaction.
Troubleshooting
“SSL support is not compiled in” usually points to the client binary or build options. Certificate errors point to trust, host names, or server configuration. A missing ICU/OpenSSL library is a build/runtime dependency problem; disabling TLS is not its remedy.
Recovery and next steps
Stop the lab with /opt/postgresql/17/bin/pg_ctl -D /srv/postgresql/tutorial-data stop -m fast when finished. Keep existing production binaries and data untouched. Installation alone does not migrate an old database to a new major version.