When building packages on ubuntu jammy, we started to see some warnings.
autoreconf: warning: autoconf input should be named 'configure.ac', not
'configure.in'
Instead of using the git tag that is reachable from the HEAD commit,
use the exactly matching tag in citus_version().
For the other branches (including the master), just use name of the
current branch that we are installing citus and sha of the HEAD.
This is because, we do not tag the branches except the release ones.
That way, we won't see v9.2.3-DO-NOT-INSTALL tag anymore in the output
of the citus_version();
DESCRIPTION: add gitref to the output of citus_version
During debugging of custom builds it is hard to know the exact version of the citus build you are using. This patch will add a human readable/understandable git reference to the build of citus which can be retrieved by calling `citus_version();`.
These hadn't been looked at in a while, and I'm somewhat certain they
actually were running with optimization on, which is pretty bad.
Swapped out the lower-level flags for `--coverage`, which will work
with both `clang` and `gcc`. On some platforms, linker flags are need-
ed as well.
Adds ```citus.enable_statistics_collection``` GUC variable, which ```true``` by default, unless built without libcurl. If statistics collection is enabled, sends basic usage data to Citus servers every 24 hours.
The data that is collected consists of:
- Citus version
- OS name & release
- Hardware Id
- Number of tables, rounded to next power of 2
- Size of data, rounded to next power of 2
- Number of workers
1) Generated files reside in the build directory, not the source
directory.
2) As a generated file is now included in the build, add it to the
include path (-I)
With this change, we start to error out if loaded citus binaries does not match
the available major version or installed citus extension version. In this case
we force user to restart the server or run ALTER EXTENSION depending on the
situation
That's useful when trying to rely on files only present in source and/or
build directories, not in the normal installation. E.g. the
isolationtester binary, or the valgrind suppression files.
If postgres was compiled without flex support - possible when building
from a tarball, because those contain the flex generated files - citus
compilation would fail, because FLEX is defined as missing.
Add detection for flex, overwriting postgres' detection if one was
found.
Fixes: #439
I came across several places we weren't as flexible or resilient as we
should have been in our build logic. They include:
* Not using `DESTDIR` in the install-header destination
* Allowing callers to specify `VPATH` or `srcdir` (which breaks)
* Using absolute path for SCRIPTS (9.5 prepends srcdir)
* Including libpq-int in a confusing way (extracted this function)
* Having server includes come first during csql build (client must)
In particular, I hit all of these attempting to build with pg_buildext
in Debian. It passes in an explicit VPATH, as well as srcdir (breaking
all recursive make invocations), and also uses DESTDIR during install.
In addition, a PGDG-enabled Debian box will have the latest libpq-dev
headers (e.g. 9.5) even when building against an older server version
(e.g. 9.4). This leads to problems when including e.g. `c.h`, which
is ambiguous. While compiling more client-side code (csql), we need to
ensure the newer libpq headers are included _first_, so I fixed that.
All citusdb references in
- extension, binary names
- file headers
- all configuration name prefixes
- error/warning messages
- some functions names
- regression tests
are changed to be citus.
Hanefi Onaldi
Onur Tirtir
Nils Dijk
Jason Petersen
Hadi Moshayedi
Andres Freund
Burak Yucesoy
Murat Tuncer
Onder Kalaci