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();`.
This change was actually already intended in #3124. However, the
postgres Makefile manually enables this warning too. This way we undo
that.
To confirm that it works two functions were changed to make use of not
having the warning anymore.
This makes three warnings hard errors:
1. `implicit-int`
> Warn when a declaration does not specify a type.
2. `implicit-function-declaration`
> Give a warning whenever a function is used before being declared.
3. `return-type`
> Warn whenever a function is defined with a return type that defaults to
> "int". Also warn about any "return" statement with no return value in
> a function whose return type is not "void" (falling off the end of the
> function body is considered returning without a value).
>
> For C only, warn about a "return" statement with an expression in a
> function whose return type is "void", unless the expression type is
> also "void".
The compiler behaviour when these warnings occur is not the behaviour
the developer expects. So even during development it makes sense that
they are errors.
When adding a `-Wno-some-error` flag, instead of trying to check for
`-Wno-some-error` support this checks for `-Wsome-error` support.
This is done because currently there's the a problem when compiling
citus with `./configure CFLAGS=-Werror`. If there's a warning (which is
then converted to an error) in addition to this error, the output will contain
the following message with GCC 7:
```
cc1: error: unrecognized command line option ‘-Wno-gnu-variable-sized-type-not-at-end’ [-Werror]
```
This is because of the following behaviour of GCC in case of unknown warnings:
> When an unrecognized warning option is requested (e.g., -Wunknown-warning), GCC
> emits a diagnostic stating that the option is not recognized. However, if the
> -Wno- form is used, the behavior is slightly different: no diagnostic is
> produced for -Wno-unknown-warning unless other diagnostics are being produced.
> This allows the use of new -Wno- options with old compilers, but if something
> goes wrong, the compiler warns that an unrecognized option is present.
By changing the check to `-Wsome-error`, the check will actually fail
when the warning is not supported. Instead of silently being ignored
when checking, but then coming up when another error happens.
Everything supports this, works in clang 6 and gcc 4.7
Also removes -Wdeclaration-after-statement, since declarations
after statements are only not supported in ISO C90.
Fixes#3122
@thanodnl told me it was a bit of a problem that it's impossible to see
the history of a UDF in git. The only way to do so is by reading all the
sql migration files from new to old. Another problem is that it's also
hard to review the changed UDF during code review, because to find out
what changed you have to do the same. I thought of a IMHO better (but
not perfect) way to handle this.
We keep the definition of a UDF in sql/udfs/{name_of_udf}/latest.sql.
That file we change whenever we need to make a change to the the UDF. On
top of that you also make a snapshot of the file in
sql/udfs/{name_of_udf}/{migration-version}.sql (e.g. 9.0-1.sql) by
copying the contents. This way you can easily view what the actual
changes were by looking at the latest.sql file.
There's still the question on how to use these files then. Sadly
postgres doesn't allow inclusion of other sql files in the migration sql
file (it does in psql using \i). So instead I used the C preprocessor+
make to compile a sql/xxx.sql to a build/sql/xxx.sql file. This final
build/sql/xxx.sql file has every occurence of #include "somefile.sql" in
sql/xxx.sql replaced by the contents of somefile.sql.
See a9c35cf85c
clang raises a warning due to FunctionCall2InfoData technically being variable sized
This is fine, as the struct is the size we want it to be. So silence the warning
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.
VLAs aren't supported by Visual Studio.
- Remove all existing instances of VLAs.
- Add a flag, -Werror=vla, which makes gcc refuse to compile if we add
VLAs in the future.
This patch adds --with-reports-host configure option, which sets the
REPORTS_BASE_URL constant. The default is reports.citusdata.com.
It also enables stats collection in tests.
This will provide the full project name (i.e. Citus/Citus Enterprise),
and the host system, compiler, and architecture word size.
I wanted to limit the number of copied files in 'config', so I added
only config.guess and call it manually, rather than using the macro
AC_CANONICAL_HOST, which requires several other files.
PostgreSQL has it, now we do too!
Example: `./configure --with-extra-version=+git.20171011.a1387f4` would
currently result in: `` reporting the more useful:
SHOW citus.version;
citus.version
-------------------------------
7.1devel+git.20171011.a1387f4
Nice to have for packaging, one-off customer builds, etc. This stuff
is generally already in the package metadata, but it will be nice to
have it directly within a psql session.
Eclipse apparently doesn't scan build output looking for -D flags, so
having the value actually appear in a header is nicer for those of us
using IDEs.
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
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.
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.
The use of a bare src/ rather than $srcdir caused configure to fail
during VPATH builds. With our additional dependency upon AWK, we need
to call AC_PROG_AWK, otherwise environments may not have $AWK set.
Finally, citus_version.h should be in .gitignore.
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
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.
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.
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.
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
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.
Onur Tirtir
Marco Slot
Nils Dijk
Hanefi Onaldi
Jelte Fennema
SaitTalhaNisanci
Philip Dubé
Jason Petersen
Jason Petersen
Jason Petersen
mehmet furkan şahin
velioglu
Brian Cloutier
Hadi Moshayedi
Hadi Moshayedi
Burak Yucesoy
Andres Freund
Murat Tuncer
Onder Kalaci