Support for using the TAP protocol to run extended regression tests was added to PostgreSQL back in 9.4 with the adoption of Perl's prove tool and Test::More to test initdb, pg_basebackup, etc.
Since then the TAP-based tests have been greatly expanded, particularly with the advent of the src/test/recovery tests and the PostgresNode module in PostgreSQL 9.6. PostgreSQL now comes with a built-in test harness for easily starting up postgres instances, creating and restoring backups for replication, setting up streaming, and lots more.
You can now use this to test your extensions.
pg_regress and its limitations
Extensions have long supported pg_regress based tests. Just drop the test scripts in sql/. Put the expected results in expected/. List the test names (sans directory and file (more…)
We have made pglogical 1.1 packages available for PostgreSQL 9.6beta1 for both rpm and deb based distributions. They are available for install from our standard pglogical package repository.
You may ask why do we release packages for beta version of Postgres? Well, one of the reasons is that you can use pglogical to replicate your existing PostgreSQL 9.5 or 9.4 database to the 9.6beta1 in real-time and run tests on it to help weed out any remaining bugs in the beta release. Here is a quick tutorial on how to do that.
Many years ago, Michelle Caise submitted a patch to generate code coverage reports for the PostgreSQL code base, based on the lcov utility. Although I cannot find any record of an actual patch in the mailing list archives, Peter Eisentraut committed it some time later, and applied further refinements later.
Today I'm announcing a new PostgreSQL community service: code coverage reports generated automatically and updated daily using this infrastructure. I explain more details here (more…)
People are often hesitant to test out a new PostgreSQL release because they're concerned it'll break their current working installation.
This is a perfectly valid concern, but it's easily resolved with a few simple protective measures:
Build PostgreSQL from source as an unprivileged user
Install your PostgreSQL build within that user's home directory
Run PostgreSQL as that user, not postgres
Run on a non-default port by setting the PGPORT env var
If you take these steps the install its self cannot interfere at all. Starting and running the new PostgreSQL can only interfere by using too many resources (shared memory, file descriptors, RAM, CPU, etc) and you can just stop the new version if it causes any issues. The shared memory improvements in 9.3 make the shared memory (more…)