[dyber-pqc]

Problem

On a build with liboqs linked and fully functional, the postmaster still logs at startup:

FortressQL: PQC subsystem initialized (liboqs available: no)

This is a false negative. liboqs is present and works — for example SELECT pqc_sig_keygen('ML-DSA-65') returns a valid keypair, and ldd .../bin/postgres shows liboqs.so.

Root cause

pqc_preflight_check() (called from the postmaster) logs the status via pqc_is_available(), which returns the static pqc_initialized flag. That flag is set only by pqc_init() (which calls OQS_init()), and pqc_init() was invoked lazily — only from the KEM/SIG paths in pqc_kem.c / pqc_sig.c on first use.

So at startup the preflight check reads the flag before anything triggers the lazy init, and logs no. Because the flag is process-local and the postmaster never initializes it, each backend also re-initializes liboqs independently on first PQC use, rather than inheriting an initialized state across fork().

Fix

Initialize the subsystem once, eagerly, in pqc_preflight_check() before logging the status. pqc_init() is idempotent, so this is safe, and forked backends inherit the initialized state.

One line of behavior change:

+	(void) pqc_init();
 	/* Log PQC subsystem status */

Verification

Built FortressQL (PostgreSQL 17, -Dpqc=enabled -Dssl=openssl) against liboqs 0.16.0 on OpenSSL 3.5. Before the fix the postmaster logged liboqs available: no; after it logs:

FortressQL: Post-Quantum Cryptography initialized (liboqs)
FortressQL: PQC subsystem initialized (liboqs available: yes)

Note: this relies on the standard fork-based backend model (children inherit the initialized state). An EXEC_BACKEND build would still initialize per backend on first use via the existing lazy path, which is unchanged.