TM Port report PostgreSQL vs the operating systems 

Windows = supported = not supported = back branches only [both] 12-15 12-16 

Windows 12-15 12-16 Rough guess of relative number of users 

Windows 12-15 12-16 Rough guess of relative amount of noise,
 breakage, CI failures, port-speci fi c commits 

AIX Dropped in 17, request lodged to bring it back for 18 • Di ffi culties: • Old OS versions only in build farm (since improved), old compiler with bugs requiring investigation and workarounds (ditto) • No active users or vested-interested build farm owners • Vendor compiler xlc required extra work (itself now partially replaces by Clang infrastructure), but it was unclear whether we could just drop that and require gcc/clang • Unusual linker/object format (XCOFF) and tools • Hard to deal with adding new dependencies like Meson which may not have been ported • A team at IBM itself reached out o ff ering to supply machines and labour as they have products the port 

HP-UX Dropped in 16 due to end of CPU • No complaints! 

Solaris • Dropped support for Solaris 11.3 in 17. We acted in anticipation of EOL, see commit “All supported systems have locale_t.”. Now Oracle has announced an extension of 3 more years… I think we can just ignore that. • One active Solaris 11.4 animal and two active illumos animals (an open source cousin), owners reactive to queries/requests for help with vested interest in the port. Testing only with GCC. • REL_16_STABLE and earlier are being tested on wrasse, Solaris 11.3, Oracle Developer Studio 12.6 (released 2017, but there have been no updates since), a compiler that we carry special code for guarded by __SUNPRO_C. That is untested in 17+. Time to drop? • A few optional features don’t work and are unlikely to be implemented: direct I/O, LLVM, e ffi cient latch.c. 

OpenBSD • Uncommonly narrow vendor-support window: 1 year. • It makes it quite di ffi cult to decide on the relevance of EOL build farm animals. At least we got rid of the animals that were requiring us to remain compilable on GCC 4.2… • One interesting point: OpenBSD uses LibreSSL (a fork of OpenSSL that we support). We have two 3 year old OpenBSD 6.9 (~3 year old) systems running LibreSSL 3.3.2, creating another kind of horizon that is “not real”. (macOS also uses LibreSSL?) 

Linux + musl • musl (clean-room non-GPL alternative to glibc, primarily used by Alpine, a distro popular in containers) came onto our radar due to an incompatibility with something we’d been doing for years. That produced a fi x, and Alpine Linux (the main user) has been added to the build farm. 

Windows The good news • Old Perl-based build system removed 

Windows Ongoing struggles for users • Locale name instability broke all the databases in Türkiye (formally Turkey) • Historical locale name changes handled by hard-coded table; change now proposed to support renaming on the fl y from a text fi le; indications good but testers needed (I will post a version that can be tested on Unix too) • RelationTruncate() fails because ftruncate() fails with permission error • Database then becomes corrupted; work needed to make it PANIC (patch proposed, not enough yet) (a ff ects all OSes, but failure is not expected) • Research needed to fi nd cause of that error 

Windows Ongoing struggles in the build farm • Socket event loss • Various code paths can miss an FD_CLOSE; ancient design mistake • Solution proposed, it seems to work according to testing by Alexander Lakhin, but it’s ugly :-( add a MSG_PEEK • Also a ff ects real users, because it means we can’t close server sockets gracefully, but that means that we also sometimes lose fi nal messages sent before close 

Windows File link workarounds • Lots of strange workarounds and wrappers to sleep and retry on fi le system operations relating to directory entries that can fail for reasons that are strange to Unix hackers • Enable “POSIX mode” linking? But that will make PostgreSQL not work on network fi lesystems and ReFS, because they don’t support it! Which committee is in charge of making decisions like that? 

And much more…