Surprisingly adding a no-op change like:

--- a/pkgs/servers/sql/postgresql/generic.nix
+++ b/pkgs/servers/sql/postgresql/generic.nix
@@ -447,0 +448,2 @@ let
+      FOO = "42";
+

fixes the build. As if there is some ordering issue in nix to discover known outputs.

What should builtins.sort (a: b: true) [ 1 2 3 ]even do? Should this be a nix language-level UB? Currently manual does not provide any preconditions https://nix.dev/manual/nix/2.25/language/builtins.html?highlight=builtins.sort#builtins-sort.

This would be a tricky thing to fix. Failing gracefully would require validating the strict weak ordering or using sorting algorithms that do not explode when the comparator is broken. std::sort can easily explode since it's something like qsort. stable_sort is actually a combination of insertion sort with merge sort on top. https://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USERS-4.4/a01347.html#l03409

I think using a custom merge sort would be safe even for broken predicates and won't crash nix evaluator, but this would still need to be nix UB (such calls to sort are ill-formed and diagnosing it is prohibitively expensive).

Either way this calls for a custom sorting implementation that does not assume that the provided predicate is strict weak ordering.

In reply to @xokdvium:matrix.org

What should builtins.sort (a: b: true) [ 1 2 3 ]even do? Should this be a nix language-level UB? Currently manual does not provide any preconditions https://nix.dev/manual/nix/2.25/language/builtins.html?highlight=builtins.sort#builtins-sort.

This would be a tricky thing to fix. Failing gracefully would require validating the strict weak ordering or using sorting algorithms that do not explode when the comparator is broken. std::sort can easily explode since it's something like qsort. stable_sort is actually a combination of insertion sort with merge sort on top. https://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USERS-4.4/a01347.html#l03409

I think using a custom merge sort would be safe even for broken predicates and won't crash nix evaluator, but this would still need to be nix UB (such calls to sort are ill-formed and diagnosing it is prohibitively expensive).

Either way this calls for a custom sorting implementation that does not assume that the provided predicate is strict weak ordering.

Yup, that's clearly a huge problem and this should be fixed by not using standard sorting algorithms:

Either way this calls for a custom sorting implementation that does not assume that the provided predicate is strict weak ordering.

What I'm trying to say is that this should still be UB in the nix language, but not crash and burn the evaluator.