WIP: OPFS VFS experiments

[samwillis]

Update

The "access handle pool" vfs has been forked out into this PR #130 , aiming to merge it.

---

This branch includes a couple experimental OPFS VFSs:

opfs-worker

This is a new custom VFS for OPFS, it uses a WebWorker with SharedArrayBuffers and Atomics to enable use of the async OPFS APIs. (Its not suing WASMFS as that would require a separate build)

It's currently a little slow as no care for optimisations have been taken.

On the to do list:

• Ensure we are copying the minimum number of times on read/write
• Where possible use shared memory for the WASM heap and share it will the OPFS worker, we then can copy from the file directly to the heap and back. (This will likely require a separate WASM binary with shared memory enabled)

opfs-ahp

This is an "access handle pool" VFS inspired by the AHP SQLite VFSs.
Essentially it opens a large pool of sync access handles before Postgres startes, and uses them to create a VFS layered on top of OPFS.

Your datadir looks like:

• state.jsonl
• data
  • 00000-000001
  • 00000-000002
  • ...

state.jsonl is a log file to maintain the tree of the VFS, each file under data/ is mapped to a specific file in the VFS.
The state file is a WAL, so it's quick to append to and rolls back if an operation fails. There is then a periodic checkpoint wher the state file is rewritten and compressed. (I suspect there is a race condition here currently as OPFS doesn't have an atomic rename/move, but solvable)
I call .flush() on the file handles for the Postgres WAL files if they are modified during a query to attempt some high durability.

We already had a "relaxed durability mode" for the IDB VFS (its so slow to flush whole files), and so I've also added one to the OPFS AHP VFS - this just skips the flush of the Postgres WAL files and lets the OS schedule a flush. It's very very quick, only a touch slower then in-memory. I suspect for most embedded use cases this is absolutely suitable.