[DRAFT - held on OSv fork/COW landing] postgres18-musl: stock PostgreSQL 18 on OSv demo

[gburd]

Draft — held on the OSv fork/COW work landing on OSv master

Adds a postgres18-musl/ demo app that runs stock, unmodified PostgreSQL 18
(musl build) on OSv.

This will NOT run on stock OSv master. It requires the OSv-side
thread-backed fork() + per-child COW address space + per-process signals + the
fork-completeness stack (AS-aware mmap, fd inheritance, timer parking, cross-AS
coherence) to be present on OSv master first. Until then this is filed as a
draft so the app is visible alongside the kernel work it depends on.

Requires (on OSv, not this repo)

• process: implement thread-backed fork()/vfork()/execve()/waitpid() (opt-in, off by default) osv#1455 — thread-backed fork()/vfork()/execve()/waitpid()
• mm: per-child copy-on-write address space for fork() (opt-in, stacked on #1455) osv#1456 — per-child copy-on-write address space for fork()
• libc: honor POSIX default-ignore disposition for SIGCHLD/SIGURG/SIGWINCH osv#1457 — POSIX default-ignore SIGCHLD/SIGURG/SIGWINCH
• the fork-completeness stack tracked in [DRAFT / tracking - DO NOT MERGE as one unit] PostgreSQL-on-OSv fork+ZFS integration (will split into S1..S6 on #1455/#1456/#1457 + #1423) osv#1458
  (S1..S6: AS-aware mmap, COW arena, fd inheritance, per-process signals,
  timer parking, cross-AS coherence), and — for ZFS-backed /data —
  zfs: selectable in-kernel ZFS (BSD or OpenZFS 2.4.2) via upstream submodule + patch series osv#1423 (selectable in-kernel OpenZFS).

All of the above are opt-in / CONF_fork on OSv; PG-per-backend fork is the
whole reason this app needs them.

Status

Ready to draft; held on fork-merge. Do not merge until the OSv fork/COW
stack (#1455/#1456/#1457 + #1458) is on OSv master; add ZFS (#1423) for the
ZFS-on-NVMe /data variant.

[gburd]

Two one-line fixes pushed, both found while verifying PostgreSQL 18's asynchronous I/O on OSv.

The build target was shadowed by the build/ directory. The Makefile declared .PHONY: module but not build, while module: build depends on a target named build and the module also creates a real build/ directory. Make sees the directory, considers the target up to date, skips the recipe, and module succeeds having built nothing. The observable result is an image with no PostgreSQL in it while the build reports success: about 10 MB where a working image is roughly 65 MB. Two separate people lost time to this before it was diagnosed. Declaring build phony as well makes the recipe always run.

Worth knowing as a check regardless of this fix: image size is a reliable smoke test here. A PostgreSQL-bearing usr.img is around 65 MB with seven manifest entries for the module; a shadowed build yields roughly 10 MB and still exits zero.

The io_method comment was wrong, and in a way that mattered. It said OSv's "io_uring/worker AIO path is incomplete", conflating two unrelated mechanisms. io_method=worker needs no kernel AIO at all: it is shared memory plus an LWLock plus a latch, with forked IO worker processes calling pg_preadv/pg_pwritev, all of which OSv already supports. Verified on OSv with PostgreSQL 18.6, checked from a client outside the guest rather than from inside it:

version:    PostgreSQL 18.6 on x86_64-pc-linux-musl, compiled by gcc (GCC) 13.3.1
io_method:  worker
io_workers: 3

PostgreSQL started cleanly, forked its three IO worker processes, reported "database system is ready to accept connections", and served queries with no faults, with PGDATA on a ZFS dataset rather than a memory filesystem.

io_uring is the genuinely incomplete one for this module, and it additionally needs --with-liburing at configure time plus liburing in the image.

Since io_method is PGC_POSTMASTER, one build can select any method at run time with -c io_method=..., so the demo default stays at sync and the comment now explains the choice instead of misstating the platform's capabilities.

[gburd]

One more fix, found while seeding a PostgreSQL cluster onto ZFS inside an OSv guest.

seed_copy preserved the source file mode, which is the right thing to do on a filesystem that has modes. rofs does not have them. scripts/gen-rofs-img.py lines 53-55 define

DIR_MODE  = int('0x4000', 16)
REG_MODE  = int('0x8000', 16)
LINK_MODE = int('0xA000', 16)

and assigns those unconditionally, so only the S_IFMT type bits are stored and the permission field is discarded entirely. rofs_getattr() then reports a hardcoded 0555 for every inode.

The consequence is that copying the observed mode created the destination tree without an owner-write bit, and the next level down failed: O_CREAT reached vn_access(VWRITE) and returned EACCES. Seeding stopped at the second directory level. A 0555 PGDATA would have been rejected by PostgreSQL anyway, so preserving that mode could never have worked.

This uses the modes initdb itself produces, 0600 for files and 0700 for directories, rather than propagating modes the source filesystem cannot represent. With it, seeding a 19 GB 200-warehouse cluster onto a ZFS dataset completes with no errors.

Worth noting separately, since it is a defect in the image tooling rather than in this module: rofs discarding permissions is invisible until something tries to write into a tree copied out of it. Anything that reads a mode from a rofs image is reading an invented value.