←back to thread

570 points davidgu | 2 comments | | HN request time: 0s | source
Show context
cpursley ◴[] No.44525353[source]
Right, plus there's character limitations (column size). This is why I prefer listening to the Postgres WAL for database changes:

https://github.com/cpursley/walex?tab=readme-ov-file#walex (there's a few useful links in here)

replies(3): >>44525747 #>>44526330 #>>44526350 #
williamdclt ◴[] No.44525747[source]
I found recently that you can write directly to the WAL with transactional guarantees, without writing to an actual table. This sounds like it would be amazing for queue/outbox purposes, as the normal approaches of actually inserting data in a table cause a lot of resource usage (autovacuum is a major concern for these use cases).

Can’t find the function that does that, and I’ve not seen it used in the wild yet, idk if there’s gotchas

Edit: found it, it’s pg_logical_emit_message

replies(3): >>44526012 #>>44528978 #>>44533458 #
cryptonector ◴[] No.44533458[source]
`pg_logical_emit_message()` is great and better than `NOTIFY` in terms of how it works, but...

`pg_logical_emit_message()` perpetuates/continues the lack of authz around `NOTIFY`.

replies(1): >>44533495 #
williamdclt ◴[] No.44533495{3}[source]
What do you mean by this? What authz would you expect/like?
replies(1): >>44535874 #
cryptonector ◴[] No.44535874[source]
I'd like to say that only some roles can NOTIFY to some channels. Similarly for alternatives to LISTEN/NOTIFY.
replies(1): >>44541453 #
1. williamdclt ◴[] No.44541453[source]
Right. It’s not something I’ve had to handle, I’ve always worked in environments where db clients are well behaved and under my control, what’s your use case out of interest?
replies(1): >>44546833 #
2. cryptonector ◴[] No.44546833[source]
Security in depth. If I have to give someone login access, I should be able to control what they do.