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.
This library is used by other packages, so should be in the lib output.
By removing unused sections, libecpg will not contain any references to other
outputs and thus does not increase the closure for the lib output anymore.
This will also help massively when splitting a dev output later.
As a side-effect, this also unbreaks pkgsMusl.postgresql_12_jit and
pkgsMusl.postgresql_13_jit. For, at least to me, unknown reasons, those build
fine now.
Dynamic modules are technically libraries, but are not used by other packages.
Instead they are loaded by PostgreSQL itself, e.g. as extensions. Those just
increased the size of the lib output without benefit.
This removes the NIX_PGLIBDIR hack introduced in #17838 and instead makes sure
that pg_config always returns the correct PGLIBDIR. The test for postgis
introduced in the same PR is still passing with the change.
* postgresqlPackages.timescaledb_toolkit: fix on macos
It looks like the macOS linker doesn’t like that some of the symbols
are undefined in the extension. They will be provided by the postgres
binary, but macOS linker checks that all symbols are defined.
Apparently, Linux allows these symbols to be undefined.
The -undefined flag changes this behavior:
> Specifies how undefined symbols are to be treated. Options are:
> error, warning, suppress, or dynamic_lookup. The default is error.
So, setting to dynamic_lookup makes the most sense here, and makes
this package work on macOS. I tried to see if pgvecto-rs, which also
uses buildPgrxExtension, would build. Unfortunately, it gave other
errors.
More information on the bug here: https://github.com/supabase/nix-postgres/issues/10
* Remove stdenv
Upstream (accidentally) broke support for postgresql 12 and 13 on
v0.2.1 by changing the signature of the `from_datum` function[^1].
This went unnoticed since the release branch `0.2` did not have CI.
Furthermore, they are removing support for these versions of postgresql
on v0.3.0[^2].
[^1]: 97e861d51d
[^2]: https://github.com/tensorchord/pgvecto.rs/issues/343
pgx had been renamed to pgrx in April 2023 already [1]. Newer versions
are already in nixpkgs as pgrx. Since the previous commit removed
the only remaining instance of a package still depending on
pgx 0.6.1, we can now remove all of buildPgxExtension and cargo-pgx.
[1]: https://github.com/pgcentralfoundation/pgrx/issues/1106
postgresql14Packages.promscale_extension breaks with:
Error:
0: `pgx-0.6.1` shouldn't be used with `cargo-pgx-0.7.4`,
please use `pgx = "~0.7.4"` in your `Cargo.toml`.
However, pinning cargo-pgx to 0_6_1 via the following
buildPgxExtension.override { cargo-pgx = cargo-pgx_0_6_1; }
does not work either, because the build then fails with:
thread 'main' panicked at /build/promscale_extension-0.8.0-vendor.tar.gz/proc-macro2/src/fallback.rs:756:9:
"__mbstate_t_union_(unnamed_at_/nix/store/ij144ma6vs8acil8r9hgr8xkb1dp9azg-glibc-2_39-5-dev/include/bits/types/__mbstate_t_h_16_3)" is not a valid Ident
This seems to be related to [1], which indicates that this is a
problem with newer LLVM / clang toolchains.
At the same time th upstream package is deprecated / archived since
the 2nd of April 2024 [2]. Additionally this package is unfree and
thus very unlikely to be forked. Since we can't expect this to be
fixed, the only sensible thing to do is to remove the package.
[1]: https://github.com/rust-lang/rust-bindgen/issues/2312
[2]: https://github.com/timescale/promscale/issues/1836
This was introduced in #228349, but doesn't seem necessary to build for pkgsMusl.
In fact the patch itself seems to be very specific about a stripped down icu
package in Alpine Linux, which does not apply to nixpkgs.
This was disabled to fix#51093. The related discussion upstream revealed that this
has been fixed in [1] for v12+. Since v12 is our oldest supported version right now,
we should be able to safely enable parallel building on darwin again.
Furthermore, it seems that this kind of issue was also fixed in #51221 and #51408
for the general case.
[1]: 826eff57c4
This was introduced in #44083 to fix cross building, where xml2-config
wouldn't run on the host platform. This was fixed upstream two years
later [1], so that from v13 on pkg-config is used before xml2-config is.
Once v12 is EOL, we can remove this entirely.
[1]: 0bc8cebdb8
This was introduced in 65fd8f3f48 around 20 years
ago as LANG=en_US, later changed to LC_ALL=en_US and LC_ALL=C to avoid bash
warnings. This might have been relevant to run initdb during the check phase, but
the PostgreSQL docs [1] say this today:
For implementation reasons, setting LC_ALL does not work for this purpose
Therefore it can be removed safely.
[1]: https://www.postgresql.org/docs/current/regress-run.html#REGRESS-RUN-LOCALE
Trying to understand what each patch does made me come up with some more
descriptive names:
- Renaming the two disable-xxx patches to a common names makes it immediately
clear that one replaces the other depending on version number.
- findstring was really not descriptive at all.
- hardcode-pgxs-path will be extended with more paths for split outputs in
a later commit. Renaming here already to allow git to better track renames.
Finally replacing HARDCODED_PGXS_PATH with $out/lib in the last patch, makes
it easier to understand what the end result will look like when reading the
patch.
More cosmetic than anything else. The description in findstring.patch was
duplicated, postgresql-9.6.1 references confusing. Timestamps are not
needed, that's what git blame is for.
Previously, it was not possible to run tests on an overridden derivation, because
the derivation under test was always pulled from pkgs.
With this change, the following will return the same test:
postgresql_jit.tests
and
(postgresql.override { jitSupport = true; }).tests
pg_safeupdate was updated to 1.5 in #269755. v1.5 is not compatible with
PostgreSQL 12 and 13 anymore, so those were marked as broken.
However, this blocks anyone using PostgreSQL 12 or 13 with pg_safeupdate
from updating nixpkgs.
Instead, the old version should have been kept for PG 12 and 13.
Previously the entire `meta` section from `pg-dump-anon` was copied
over including `mainProgram` which doesn't belong here. To avoid similar
issues, fields from the meta section of pg-dump-anon are copied over
explicitly.
