Obscure lwlock assertion failure if write fails in initdb

Hi,

In all releases, if bootstrap mode's checkpoint gets an error (ENOSPC,
EDQUOT, EIO, ...) or a short write in md.c, ERROR is promoted to FATAL
and the shmem_exit resowner machinery reaches this:

running bootstrap script ... 2023-12-14 10:38:02.320 NZDT [1409162]
FATAL: could not write block 42 in file "base/1/1255": wrote only
4096 of 8192 bytes
2023-12-14 10:38:02.320 NZDT [1409162] HINT: Check free disk space.
2023-12-14 10:38:02.320 NZDT [1409162] CONTEXT: writing block 42 of
relation base/1/1255
TRAP: failed Assert("!LWLockHeldByMe(BufferDescriptorGetContentLock(buf))"),
File: "bufmgr.c", Line: 2409, PID: 1409162

It's really hard to hit because we'd normally expect smgrextend() to
get the error first, and when it does it looks something like this:

running bootstrap script ... 2023-12-14 10:22:41.940 NZDT [1378512]
FATAL: could not extend file "base/1/1255": wrote only 4096 of 8192
bytes at block 42
2023-12-14 10:22:41.940 NZDT [1378512] HINT: Check free disk space.
2023-12-14 10:22:41.940 NZDT [1378512] PANIC: cannot abort
transaction 1, it was already committed
Aborted (core dumped)

A COW system might succeed in smgrextend() and then fail in
smgrwrite(), and any system might fail here with other errno.

It's an extremely well hidden edge case and doesn't matter to users:
initdb failed for lack of space or worse, the message is clear and the
rest is meaningless detail of interest to developers with assertion
builds. I only happened to notice because I've been testing short
write and error scenarios via artificially rigged up means for my
vectored I/O work. No patch, I just wanted to flag this obscure
pre-existing problem spotted in passing.