fix(entrypoint): pipe *.sql into isql to avoid 1-byte read amplification

[fdcastel]

Summary

Fixes #40. Restores the v1-style cat "$f" | process_sql for plain SQL files in init_db(), in place of the v2 redirect form process_sql < "$f".

Root cause

isql reads stdin one byte per read() syscall. The cause isn't a missing stdio buffer — isql is statically linked against the bundled editline from extern/editline/, and its read_char() calls raw read(fd, _, 1) per character, bypassing stdio entirely (so e.g. setvbuf(stdin, …) would not help). With cat | isql, those byte-reads come from a kernel pipe (in-memory, lock-free). With isql < file, every byte-read goes through the regular-file path (i_rwsem, atime, FS layer).

strace -c against the example.fdb repro from #40 (~110 KB schema): isql issues ~95 600 single-byte reads on FD 0 in both modes. The number of syscalls is identical; the per-call latency is what differs.

Why the magnitude is host-dependent

On native disk (no FS layering), pipe vs regular-file read() differ by tenths of a microsecond, so the total init delta is small (~50 ms locally, ~25 % of init time). But on layered or remote filesystems — Docker Desktop bind mounts on macOS/Windows (gRPC FUSE / virtiofs), NFS, sshfs, FUSE-overlay — every read() round-trips through a userland helper and adds tens to hundreds of microseconds. Multiplied by ~95 600 syscalls, that turns into seconds.

Demonstrated by injecting per-read() latency via LD_PRELOAD (regular-file FDs only, mimicking what FUSE/virtiofs add over the kernel-pipe path):

injected per-read delay	cat | isql	isql < file
0 μs (native)	0.17 s	0.22 s
25 μs	0.32 s	7.56 s
50 μs	0.37 s	9.95 s
100 μs	0.45 s	14.75 s

cat | isql barely moves because cat reads the file in ~10 large chunks, amortising the FS overhead. isql < file scales linearly with per-syscall cost. The 25–50 μs row is the realistic regime for Docker Desktop bind mounts and matches the 8–9 s reported in #40.

Verification

Ran the user's exact repro from #40 (compose.yaml + 01-schema.sql) on native ZFS:

variant	init.d phase
v1 5.0.3 (digest-pinned, fast)	~0.18 s
v2 5.0.3-bookworm (slow, master)	~0.23 s
v2 5.0.3-bookworm + v1 entrypoint mounted	~0.18 s
v2 5.0.3-bookworm + this fix	~0.18 s

Native-disk fix is small (~50 ms) — expected. The win comes on the FS shapes that amplify per-syscall cost; the synthetic-latency table above shows the fix collapses 8–15 s back to sub-second.

Why pipe (not isql -i)

Three options were tested at 0 μs delay:

• cat "$f" | process_sql — ~0.175 s (this PR)
• process_sql < "$f" — ~0.223 s (current master, regressed)
• process_sql -i "$f" — ~0.166 s (slightly faster still)

isql -i is marginally faster because it fopen()s the file itself and gets default stdio buffering, but switching to it changes process_sql's call shape (would no longer be uniform with the compressed cases) and would require touching the function signature. The pipe form is the minimal, surgical revert and matches the existing shape of *.sql.gz / *.sql.xz / *.sql.zst (which already use a decompressor pipeline).

Changes

• src/entrypoint.sh: one-line revert in init_db() for the *.sql case.
• generated/*/*/entrypoint.sh: regenerated (byte-identical to src/entrypoint.sh).
• DECISIONS.md: new D-016 recording the rationale.

Test plan

• User's repro from latest 5 build causes our initialisation script to take around 18 times longer than previous version #40 (example-issue-40.zip) reproduces locally on master and is fixed by this branch (native-disk magnitude).
• LD_PRELOAD per-read delay reproduces the 8–10 s magnitude reported by @erikv-hill-labs on master, and fixes it on this branch.
• All generated/*/*/entrypoint.sh are in sync with src/entrypoint.sh.
• CI matrix passes (existing image tests cover init_db via /docker-entrypoint-initdb.d/).
• User confirms in latest 5 build causes our initialisation script to take around 18 times longer than previous version #40 that this fix restores fast init on their box.