Hi all,

I'm patching SQLite to automatically set the pager to exclusive locking mode when opening a WAL mode database through a VFS that does not support shared memory.

Basically the idea is to handle setting locking mode (as described below) automatically: https://www.sqlite.org/wal.html#noshm

Specifically, this is the patch: https://github.com/ncruces/go-sqlite3/blob/v0.13.0/sqlite3/locking_mode.patch

Would this be an acceptable change to SQLite? Conversely, is this a really bad idea for some reason I'm not foreseeing?

I'd really appreciate any feedback! Thanks!

A polite bump to see if I can get some answers.

It seems to me that this would greatly improve the usability of WAL mode where shared memory is not available.

Thanks!

t seems to me that this would greatly improve the usability of WAL mode where shared memory is not available.

Just FYI: your post isn't being ignored, but the proposed change carries an as-yet-uncertain amount of risk with it for certain clients.

The current thinking (subject to change!) is that we may want to add, if it isn't already available, a parameter for URI-style db names which tells it to open in exclusive locking mode.

So now that I've finally managed to implement mmap on macOS and Linux, I'm abandoning this patch.

Now I'm wondering about the pPager->noLock test. This makes WAL incompatible with the URI parameter nolock=1. Is this intentional?

Now I'm wondering about the pPager->noLock test. This makes WAL incompatible with the URI parameter nolock=1. Is this intentional?

Yes: src:74f5d3b07f

Humm. Thanks!

I understand that locks are absolutely needed for shared memory WAL, but I'm left wondering why it doesn't work when pPager->exclusiveMode…?

I mean, it's obviously dangerous but it doesn't seem any more dangerous than with rollback journal modes, then.