Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 18 additions & 0 deletions Dockerfile
Original file line number Diff line number Diff line change
@@ -0,0 +1,18 @@
FROM postgres:14

RUN apt-get update \
&& apt-get -y install \
build-essential \
postgresql-server-dev-all \
postgresql-server-dev-14

RUN apt-get update && apt-get -y install postgresql-14-pgtap

COPY build_for_tests.sh /

RUN echo "max_locks_per_transaction = 128" >> /postgresql.conf

# The image docs tell you this isn't recommended, but this is image is only
# intended for locally running the test suite anyway, so it's appropriate
# for ease of use in this case.
ENV POSTGRES_HOST_AUTH_METHOD=trust
3 changes: 2 additions & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -96,6 +96,7 @@ See the [pg_partman.md file](doc/pg_partman.md) in the doc folder for full detai

TESTING
-------

This extension can use the pgTAP unit testing suite to evalutate if it is working properly (http://www.pgtap.org).
WARNING: You MUST increase max_locks_per_transaction above the default value of 64. For me, 128 has worked well so far. This is due to the sub-partitioning tests that create/destroy several hundred tables in a single transaction. If you don't do this, you risk a cluster crash when running subpartitioning tests.

See the [testing README](test/README_test.md) for more information.
13 changes: 13 additions & 0 deletions build_for_tests.sh
Original file line number Diff line number Diff line change
@@ -0,0 +1,13 @@
#! /bin/bash

set -e

cd /home/pg_partman

make && make install

psql -U postgres -c "DROP DATABASE IF EXISTS partman_test"
psql -U postgres -c "CREATE DATABASE partman_test"
psql -U postgres -d partman_test -c "CREATE EXTENSION pgtap"
psql -U postgres -d partman_test -c "CREATE SCHEMA partman"
psql -U postgres -d partman_test -c "CREATE EXTENSION pg_partman SCHEMA partman"
29 changes: 28 additions & 1 deletion test/README_test.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,10 @@ http://pgTAP.org/

A minimum version of pgtap 0.99.1 is required for pg_partman's test suite.

## General Setup

WARNING: You MUST increase `max_locks_per_transaction` above the default value of 64. For me, 128 has worked well so far. This is due to the sub-partitioning tests that create/destroy several hundred tables in a single transaction. If you don't do this, you risk a cluster crash when running subpartitioning tests.

Tests assume that the required extensions have been installed in the following schemas:

pg_partman: partman
Expand All @@ -20,7 +24,30 @@ Once that's done, it's best to use the **pg_prove** script that pgTAP comes with

pg_prove -ovf /path/to/partman/test/*.sql

For most tests, they must be run by a superuser since roles & schemas are created & dropped as part of the test. There is a separate test script for each of the partitioning types. The tests are not required to run pg_partman, so if you don't feel safe doing this you don't need to run the tests. But if you are running into problems and report any issues without a clear explanation of what is wrong, I will ask that you run the test suite so you can try and narrow down where the problem may be. You are free to look through to tests to see exactly what they're doing. All tests in the top level of the test folder are run inside a transaction that is rolled back, so they should not change anything (except jobmon logging as mentioned).
Most tests must be run by a superuser since roles & schemas are created & dropped as part of the test. There is a separate test script for each of the partitioning types. The tests are not required to run pg_partman, so if you don't feel safe doing this you don't need to run the tests. But if you are running into problems and report any issues without a clear explanation of what is wrong, I will ask that you run the test suite so you can try and narrow down where the problem may be. You are free to look through to tests to see exactly what they're doing. All tests in the top level of the test folder are run inside a transaction that is rolled back, so they should not change anything (except jobmon logging as mentioned).

## Docker Environment

If you don't have a build environment setup on your local machine, the project provides a docker container setup for your convenience. As long as Docker is installer, you can use the following commands to run tests:

# Build and start container (must be run in the project root):
docker build -t partman_test_image .
docker run -d --name partman_test -v $(pwd):/home/pg_partman partman_test_image

# Logon to container shell:
docker exec -it partman_test bash

# For each test cycle (on the container shell):
/build_for_tests.sh
pg_prove -ovf -U postgres -d partman_test /home/pg_partman/test/<test_file_path>.sql

# Tear down container:
docker stop partman_test
docker rm partman_test

The Docker container volumizes the project working directory so that any changes to your local copy of the project are reflected immediately on the container. This volumization allows rapid iteration without stopping and starting the container frequently. The [build_for_tests.sh](build_for_tests.sh) script automatically rebuilds the extension, installs it, and creates a fresh database with both pgTAP and the project extension installed.

## Specific Test Types

Tests for the time-custom partition type are in their own folder. The 30second test frequently errors out if run in certain 30 second blocks. Waiting for the next 30 second block and running it again should allow it to pass. Same goes for the 30 second test in the native folder.

Expand Down