Hacker News new | past | comments | ask | show | jobs | submit
I… really don't get this.

The people on SQLite, employed to work on this full time for over a year, have this to say (on the link I posted above):

“Because the WASM build does not have shared memory APIs, activating WAL requires that a client specifically activate exclusive-locking mode for a db handle immediately after opening it, before doing anything else with it…

“WAL mode does not provide any concurrency benefits in this environment. On the contrary, the requirement for exclusive locking eliminates all concurrency support…”

I personally worked to implement shared memory WAL for a server side Wasm port of SQLite. But random internet poster decides to “strongly expect it closer to a weekend or two of hacking.”

Please, do me a favor and do spend that weekend or two for the benefit of the rest of us all. It'll sincerely be much appreciated.

PS: it was a random internet poster¹ (who's been posting in this thread) who helped me figure out how to implement shared memory WAL for my port. It still took way more than “a weekend or two.” So if you do figure out how to crack this, I'm sure that people who've been trying for the past year² will definitely appreciate it.

1: https://github.com/ncruces/go-sqlite3/discussions/69

2: https://github.com/rhashimoto/wa-sqlite

> WAL mode does not provide any concurrency benefits in this environment.

Except we aren't interested in concurrency or performance benefits of WAL; we want it for something else entirely (replication).

Then you don't need WAL. I didn't say replication isn't possible, I said "that's not how it works."

A bunch of different people solved this already (though none in a couple of weekends); common to all of them: they don't use WAL mode.

loading story #41859123