There is no need to fire up a whole VM just to run a two line test of
creating the extension. We can use postgresqlTestExtension for that.
This has the advantage that it runs with postgresqlTestHook, so without
a VM, making it more portable.
Manually importing postgresql packages from the /pkgs/ folder or
manually importing the test from /nixos/tests/ in generic.nix is not
only ugly, but also forbidden should we ever move to pkgs/by-name.
We can achieve almost the same with a slightly different setup. We allow
overriding the postgresql package for the test via passthru.override, to
make sure that each postgresql_xx.tests.postgresql-wal-receiver is
properly teted with the right version.
This fixes the following error:
error: comparison of integers of different signs: 'ssize_t' (aka 'long')
and 'const size_t' (aka 'const unsigned long') [-Werror,-Wsign-compare]
if (part < iov[i].iov_len)
~~~~ ^ ~~~~~~~~~~~~~~
The build was failing with:
darwin/io_analysis.c:71:21: error: variable length array used
[-Werror,-Wvla]
char device_name[kMaxDiskNameSize];
^~~~~~~~~~~~~~~~
Main motivation for this is that I'd like to get a feature-freeze ping:
we have old stuff to remove and quite a bit of things ongoing here, so
explicitly being part of the check-up process seems like a good thing.
Also added myself and wolfgangwalther to it.
Those extensions don't support building with PostgreSQL 17, yet.
To make sure they will show up as build failures after the next package
upgrade, they all have version checks for their own package version
included.
Since PostgreSQL 9.4 it's possible to build with different uuid
libraries. Eversince, the postgres docs [1] have this to say:
[..] the OSSP UUID library [..] is not well maintained, and is
becoming increasingly difficult to port to newer platforms. [..]
On Linux, OS X, and some other platforms, suitable functions are
provided in the libuuid library, which originally came from the
e2fsprogs project (though on modern Linux it is considered part of
util-linux-ng).
Using e2fs for Darwin was introduced 9 years ago in #8574, which library
to use for Linux was never considered again. Thus, start building with
newer libs now.
As a side effect, we require one less patch if we decide to build with
meson later.
[1]: https://www.postgresql.org/docs/current/uuid-ossp.html
doCheck was enabled in #61395 which does not mention an explicit decision
for "check" instead of "check-world". The latter runs more tests, for example
for contrib modules etc. - but results in higher build times..
Running "nix-build -A postgresql":
- with doCheck = false: 46s
- with checkTarget = "check": 60s
- with checkTarget = "check-world": 75s
/bin/locale doesn't exist on musl and was already effectively disabled
in #228349. However this still leaves the following warning for initdb:
performing post-bootstrap initialization ... sh: locale: not found
By applying the alpine patch to disable locale -a entirely, this warning
will disappear. This will also make one more regression test pass when
testing "check-world" instead of "check", only.
In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
The withPackages scope now provides a "postgresqlTestExtension" helper
which removes all the boilerplate for those kind of tests.
This was Mario Rodas' idea in #299756.
This fixes some build systems which look up the location of pg_config
via the location of the postgres binary itself, e.g. timescaledb,
instead of calling pg_config which is on PATH.
Since the -dev output is correctly placed before the default output of
postgresql in PATH, we can rely on that and call "pg_config" from the
default output's fake script. Only do that, when the one on PATH is
actually a different file, though, to prevent infinite loops.
Resolves#341408
We introduced LTO in #294504. At that time, we still needed to use LLVM
/ lld to make this work on darwin. For this to work for extensions, they
would need to set CFLAGS=-fuse-ld=lld, too. However, since #307880
landed, we don't need to do this anymore in the first place, LTO just
works out of the box on darwin.
Resolves#342362
This was supposed to happen in #294504, but the commit was accidentally
left out when splitting off some libpq-related changes. Originated in
#179962, by Sandro.
Co-authored-by: Sandro Jäckel <sandro.jaeckel@gmail.com>
Co-authored-by: Wolfgang Walther <walther@technowledgy.de>
The !isDarwin condition seems to have been put in place only because of the
use of patchelf, which in turn seemed to be necessary because of nuke-refs.
Replacing the big nuke with the more granular remove-references-to allows
enabling this for darwin, too.
This splits a dev output to make the default output not depend on any
build dependencies anymore. This also avoids removing references from
pgxs' Makefile this way, which should, at least theoretically, be good
to build extensions via pgxs, making sure they use the same tooling.
ecpg is the "embedded SQL C preprocessor", which is certainly a dev
tool.
Most important, for closure size anyway, is to move pg_config to the dev
output, since it retains paths to all the other outputs.
The only thing with references to the dev output remaining is then the
postgres binary itself. It contains all the output paths, because it
shows those in the pg_config system view. There is no other way than
to nuke those references to avoid circular dependencies between outputs
- and blowing up closure size again.
