Live data from Hacker News

Show HN: Honker – Postgres NOTIFY/LISTEN Semantics for SQLite

github.com

81–90 of 95 posts

Re: Show HN: Honker – Postgres NOTIFY/LISTEN Semantics for SQLite

#81

Earlier quoted context omitted.

Yeah the C API seems like a perfect fit for this use-case: > [SQLITE_FCNTL_DATA_VERSION] is the only mechanism to detect changes that happen either internally or externally and that are associated with a particular attached database. Another user itt says the stat(2) approach takes less than 1 μs per call on their hardware. I wonder how these approaches compare across compatibility & performance metrics.

I just tested this out. PRAGMA data_version uses a shared counter that any connection can use while the C API appears to use a per-connection counter that does not see other connections' commits.

Really? That's the opposite of what I understand the docs say.

Care to share your code? This may become a bug report.

Re: Show HN: Honker – Postgres NOTIFY/LISTEN Semantics for SQLite

#82

Very neat! I like this a lot, nice work. After peeking the source, a few possible areas of improvement: - You can use `fstat` and keep a file handle around, likely further improving performance (well, reducing the performance hit to other users of the filesystem by not resolving vfs nodes). If you do this, you'll have to check for file deletions. - If you do stick with stat(2), it might be a good idea to track the in…

Wow, thanks for the great feedback. I actually looked at fstat, but the "check for deletions" piece, given I'm polling at 1kHZ, was the reason I decided not to use it. Older hardware actually made this a big issue but it's fast enough now I decided it wasn't a problem. I'll ignore the malicious ones bc [out of scope declaration]. Object paranoia is an artifact of build trama and I respect that lmao. I've just looked…

Hope it helps!

One clarification: by "check for deletions" I didn't mean that you need to read back through the filesystem; you can check for deletions for free using fstat(2)'s result. The number of hard links to a file descriptor's underlying description returned by fstat includes the "existential" hard link of the file itself, and drops to zero when the file's deleted and the open handle is an orphan:

    import os
    import time
    from threading import Thread, Event

    f = '/tmp/foo.test'
    ev = Event()
    Thread(target=lambda: ev.wait() and os.unlink(f), daemon=True).start()

    with open(f, 'w+') as fh:
        print("before delete:", os.fstat(fh.fileno()).st_nlink)
        ev.set()
        time.sleep(1)
        print("after delete:", os.fstat(fh.fileno()).st_nlink)

Re: Show HN: Honker – Postgres NOTIFY/LISTEN Semantics for SQLite

#83

Earlier quoted context omitted.

I just tested this out. PRAGMA data_version uses a shared counter that any connection can use while the C API appears to use a per-connection counter that does not see other connections' commits.

Really? That's the opposite of what I understand the docs say. Care to share your code? This may become a bug report.

Will do

Re: Show HN: Honker – Postgres NOTIFY/LISTEN Semantics for SQLite

#84

Earlier quoted context omitted.

Wow, thanks for the great feedback. I actually looked at fstat, but the "check for deletions" piece, given I'm polling at 1kHZ, was the reason I decided not to use it. Older hardware actually made this a big issue but it's fast enough now I decided it wasn't a problem. I'll ignore the malicious ones bc [out of scope declaration]. Object paranoia is an artifact of build trama and I respect that lmao. I've just looked…

Hope it helps! One clarification: by "check for deletions" I didn't mean that you need to read back through the filesystem; you can check for deletions for free using fstat(2)'s result. The number of hard links to a file descriptor's underlying description returned by fstat includes the "existential" hard link of the file itself, and drops to zero when the file's deleted and the open handle is an orphan: import os im…

Ha. Great callout. Will inspect further

Re: Show HN: Honker – Postgres NOTIFY/LISTEN Semantics for SQLite

#86

Earlier quoted context omitted.

I just tested this out. PRAGMA data_version uses a shared counter that any connection can use while the C API appears to use a per-connection counter that does not see other connections' commits.

Really? That's the opposite of what I understand the docs say. Care to share your code? This may become a bug report.

Reporting back. This appears to be a bug in my original test the code of which sadly I did not commit anywhere. I went back to regenerate these tests and proved the opposite - the C API is better than PRAGMA and works across connections. I am going to make that update as I've proved across dozens of versions of SQLite that this is not in fact the case.

Re: Show HN: Honker – Postgres NOTIFY/LISTEN Semantics for SQLite

#87

If I'm using SQLAlchemy, can this integrate? It seems to want to make the db connection itself.

I've added examples for many ORMs and web frameworks to the docs. See here:

https://honker.dev/guides/orm/#sqlalchemy--sqlmodel

Re: Show HN: Honker – Postgres NOTIFY/LISTEN Semantics for SQLite

#88

Earlier quoted context omitted.

Really? That's the opposite of what I understand the docs say. Care to share your code? This may become a bug report.

Reporting back. This appears to be a bug in my original test the code of which sadly I did not commit anywhere. I went back to regenerate these tests and proved the opposite - the C API is better than PRAGMA and works across connections. I am going to make that update as I've proved across dozens of versions of SQLite that this is not in fact the case.

Reporting back again. It seems I was actually right the first time - the C API's SQLITE_FCNTL_DATA_VERSION doesn't work cross connection. It is cached on each read - but if there aren't any reads (i.e. just polling SQLITE_FCNTL_DATA_VERSION) then it doesn't work.

PRAGMA data_version is pretty fast (1500ns with prepared statement) and doesn't have that issue.

Checking the wal-index is sub-nanosecond when mmapped but has slightly different behavior on Windows.

Here's the link to the thread on this, my scripts are all there.

https://github.com/russellromney/honker/issues/5

Re: Show HN: Honker – Postgres NOTIFY/LISTEN Semantics for SQLite

#89

Earlier quoted context omitted.

Depending on implementation details of your CPU and OS, the syscall path may need to flush various auxillary caches (like one or more TLBs) to prevent speculation attacks, which may put additional "drag" on your program after syscall return.

Correct but you’d also still have that drag just from the kernel dirtying those caches in the first place. But I was clarifying because the wording could be taken as data/instruction cache and there generally isn’t a full flush of that just to enter/leave kernel.

Yes, that’s right. It seems to make up the bulk of the cost of a system call though, depending what it does, like read or write syscalls.
Post reply on HN