Regression tests

January 16, 2019
PostgreSQL Hacking

When you (or someone else) add new features to Postgres, we need to be sure we didn’t break anything… That’s where regression tests are quite handy.

Preparing your environment

The best thing to do before testing a patch (and so before applying it) is to fetch last version of master.

git checkout master
git pull --rebase

Then you can apply your patch (as indicated in that article):

git checkout -b testing_my_awesome_patch
patch -p1 < my_awesome_patch_path

You’ll need to recompile PostgreSQL (and you might want to make a full recompile in that case because you might encountered weird errors when trying partial recompilations).

make clean

Launching regression tests

I like running tests on a temporary instance that’s created for that purpose only. That’s why I use:

make check

(First time after a make clean can be slow.)

If you have something like

 All 186 tests passed.

It means it’s goods :-).

If not, you’ll find a file called postgresql/src/test/regress/regression.diffs that will help you find what’s different between the output and the expected result. You’ll find a copy of your standard output for these tests in postgresql/src/test/regress/regression.out.

Writing regression tests

When you add new features, you need sometimes to add some tests. Regression tests are under the src/test/regress directory.

When you add some tests, you’ll need to provide the expected results. I haven’t found something less effective than running the tests once and look at the diff file. Then I inspect my results to be sure the’re good and I add them to the correct file in src/test/regress/expected/.

Do you need more ?

If you need more informations, please look at that Postgres documentation.

Can't connect to Postgres

March 30, 2020
Administration PostgreSQL Troubleshooting

Restoring Through timeline change

March 24, 2020
Installation PostgreSQL

What's wrong with Postgres?

March 22, 2020
Administration PostgreSQL Troubleshooting