This article is about PostgreSQL's own official binaries. Debian-provided packages have likewise existed for s390x for years (and continue for i386 too, which the article mentions they don't do anymore).
Where can I get info, how to make required changes to get software compiling and running on s390x? For example, some software requires CPU-specific assembler code. I can not get some code to compile correctly:
You want the principles of operations manual (that's the ISA reference) if it's seriously troublesome stuff, but usually there is no need for anything like that. Oftentimes issues are things like the system being Big Endian. If it were z/OS and not Linux you'd need to deal with a different object format and some weird calling convention stuff (even if sticking with z/OS Unix, it's not a SysV calling convention, and it's not ELF, but it is POSIX and SuS), and also EBCDIC interop possibly, so slightly more difficult, but still doesn't usually require doing any assembly. A lot of common nix software will compile and run just fine with no changes.
That's probably a heck of a lot more difficult than just running a s390x container via QEMU user mode emulation.
Even regardless of difficulty, building and running on real hardware is desirable to make sure that you've actually got a correct build going. Emulators can have bugs, including bugs that might give you a false positive about working builds when it really isn't.
The big claim to fame for the IBM Z series is supporting hot failover so the workload will never go offline. For web tier or app tier, where you want to scale horizontally anyway, it's pointless overkill, but for relational databases that have a maximum of one write master, you could make the argument that it's valuable.
I'd be interested in reading the perspective of someone actually deploying it though.
Bidirectional replication (aka multi-master) was added to Postgres in v16. Most others like MySQL, MS SQL Server, Oracle, DB2, et al have supported it for quite a while now.
Neat project, but there are easier, more cost-efficient, and well-documented methods available now.
Honestly, it just works. I can do a docker image that runs on aarch64, amd64, and s390x. For the SpringBoot apps - the hardware is rock solid and far more important, cheaper and under provisioned than the other 'standard' compute for those who have piles of legacy systems. OpenShift on zSeries is not a lot different than Intel based boxes.
The fastest z series CPUs are just modern 7nm, 8core superscalars with built in AI coprocessors, a fancy large cache arch, virtualization, and a _base_ clock of 5ghz. I imagine they aren't the wizbang magic intel has, but I doubt they are slow.
Almost 20 years (I'm getting old) ago, IBM had the eCLIPz[0] project to combine things from their Mainframe (Z) and POWER systems - it resulted in the POWER6 and z10. I assume that a lot of that sharing is still going on between the two series.
"The z10 processor was co-developed with and shares many design traits with the POWER6 processor, such as fabrication technology, logic design, execution unit, floating-point units, bus technology (GX bus) and pipeline design style, i.e., a high frequency, low latency, deep (14 stages in the z10), in-order pipeline.
However, the processors are quite dissimilar in other respects, such as cache hierarchy and coherency, SMP topology and protocol, and chip organization. The different ISAs result in very different cores – there are 894 unique z10 instructions, 75% of which are implemented entirely in hardware. The z/Architecture is a CISC architecture, backwards compatible to the IBM System/360 architecture from the 1960s. [1]
Mainframes have to implement a fifty years old architecture, and I suspect they have vastly smaller engineering teams, since their market is orders of magnitude smaller than those of Intel or ARM. Also I seem to remember IBM being seriously hostile towards independent benchmarks.
Also, if they were competitive wrt performance, people would be using them. In real life they are rarely found outside of financial institutions.
It's the size of the caches, memory bandwidth, and high core count, of some of these mainframes that make them interesting to me. It could be fun to play around.
