We made PG11 builds optional when we had an issue
with mx isolation test that we could not solve back then.
This commit solves the issue with a workaround by running
start_metadata_sync_to_node outside the transaction block.
- Lots of detail is in src/test/regress/mitmscripts/README
- Create a new target, make check-failure, which runs tests
- Tells travis how to install everything and run the tests
To be able to test landlord in travis, we need pg_stat_statements from
contrib packages. New tools version, 0.7.8, installs pg_stat_statements
too, so we are switching to version 0.7.8 in our travis tests.
Previously we compiled PostgreSQL for PR and we used already compiled
PostgreSQL packages for push builds. Compiling PostgreSQL allows us to
run isolation/vanilla tests. Thus we only ran those tests for PR builds.
We did not used compiled PostgreSQL for both builds because;
- We wanted to run our tests against packages
- Compiling takes too much time.
However, there are some benefits in using custom compiled PostgreSQL
in push builds instead of PR builds such as;
- At the moment, we do not run isolation/vanilla tests until we open a
PR, which does not make any sense.
- After merging a PR (i.e. after push to the master) push builds run
and we do not run isolation tests.
- While merging community to enterprise, we have to open a temporary
PR to make travis run isolation/vanilla tests.
- With this change master branch will have its own cache that means
every branch originated from master branch can re-use master branch's
cache. (Currently we cannot use cache for the first PR build)
With this PR we switch from using custom compiled for PR builds to push
builds.
This build is allowed to fail and finish-fast is enabled, so there is
no negative impact on developers, yet we can now stay better abreast of
upcoming PostgreSQL changes.
The latest citus tools version also adds enable-depend to the flags in
our "custom PG" source-based builds which will result in fewer false
failures due to build caching behavior.
PostgreSQL master branch is now stamped with 11devel and we should
only use master branch if we want to test against PostgreSQL 11. For
PostgreSQL 9.6 tests we should use REL9_6_STABLE and for PostgreSQL 10
we should use REL_10_STABLE. v0.6.4 tag in our tools repo addresses
this problem.
Apart from that we may want to add PostgreSQL 11 to our test matrix soon.
v0.6.4 handles that too. We just need add PostgreSQL 11 to our test matrix
and stop erroring out if we are compiling Citus against PostgreSQL 11.
Adds support for PostgreSQL 10 by copying in the requisite ruleutils
and updating all API usages to conform with changes in PostgreSQL 10.
Most changes are fairly minor but they are numerous. One particular
obstacle was the change in \d behavior in PostgreSQL 10's psql; I had
to add SQL implementations (views, mostly) to mimic the pre-10 output.
With this PR, we started to cache custom compiled PostgreSQL builds. If there
are no new commits to the related PostgreSQL branches, we will use already
compiled binaries to reduce testing time.
With this commit, we start to use custom compiled PostgreSQL builds in
Travis for merge commits. This allows us to run isolation tests and
PostgreSQL's own regression tests along with our regression tests in
Travis.
Since manually compiling PostgreSQL takes more time and we also add new
tests, we only enable running these tests on merge commits.
Adds an --enable-coverage configure option which provides the necessary
flags for coverage instrumentation. A new tools branch uses this flag
during all builds. Coverage reports are uploaded to codecov.io, where
they are publicly visible.
Adds support for PostgreSQL 9.6 by copying in the requisite ruleutils
file and refactoring the out/readfuncs code to flexibly support the
old-style copy/pasted out/readfuncs (prior to 9.6) or use extensible
node APIs (in 9.6 and higher).
Most version-specific code within this change is only needed to set new
fields in the AggRef nodes we build for aggregations. Version-specific
test output files were added in certain cases, though in most they were
not necessary. Each such file begins by e.g. printing the major version
in order to clarify its purpose.
The comment atop citus_nodes.h details how to add support for new nodes
for when that becomes necessary.
Two sets of tests are fixed by this change:
* multi_agg_approximate_distinct
* those in multi_task_tracker_extra_schedule
The first broke when we renamed stage to load in many files and was
never being run because the HyperLogLog extension wasn't easily
available in Debian. Now it's in our repo, so we install it and run
the test. I removed the distinct HLL target in favor of just always
running it and providing an output variant to handle when the extension
is absent. Basically, if PostgreSQL thinks HLL is available, the test
installs it and runs normally, otherwise the absent variant is used.
The second broke when I removed a test variant, erroneously believing
it to be related to an older Citus version. I've added a line in that
test to clarify why the variant is necessary (a practice we should
widely adopt).
This bumps the Citus tools to 0.4.0, which include support for adding
a recent (0.6.3) uncrustify to Travis in addition to support for fully
installing Travis scripts to system locations. For brevity, suffixes
have been removed from Travis shell scripts.
The main additional logic here is just ensuring Travis CI gets a newer
uncrustify install and that `citus_indent` is called with the `--check`
flag, which exits with a nonzero status if any files don't comply.
Nils Dijk
Murat Tuncer
Brian Cloutier
Jason Petersen
mehmet furkan şahin
Burak Yucesoy
Jason Petersen
Andres Freund
Onder Kalaci