Monday, February 18

Tag: testing

Using the PostgreSQL TAP framework in extensions

Craig's PlanetPostgreSQL
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…)

PGLogical 1.1 packages for PostgreSQL 9.6beta1

2ndQuadrant, Petr's PlanetPostgreSQL, pglogical, PostgreSQL
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. (more…)
Code coverage stats

Code coverage stats

Alvaro's PlanetPostgreSQL, PostgreSQL
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…)

Testing new PostgreSQL versions without messing up your existing install

Craig's PlanetPostgreSQL
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…)