You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First, what a great project! I love Postgres' LISTEN/NOTIFY feature and am using it as a key part of a system I'm currently building.
I have two questions:
Postgres has an 8000 byte limit on message payload size, and an 8 GB queue size limit for all notifies (ref: https://www.postgresql.org/docs/9.6/static/sql-notify.html). It's possible to hit the first limit very easily with a normal-sized jsonb column, and I'm not sure how many instances out there run with less than 8 GB of memory, but in the case that either limit is reached, how does Skor deal with it? Does it just pass the error from Postgres along to the caller or crash?
Since notifications have no access control, meaning any code that can connect to your database can send notification messages, message payloads can't really be trusted. In my own system, I only use them to notify the caller that something has changed. I looked briefly at https://pgxn.org/dist/pg_message_queue/, but ultimately decided to just grab the changed row when notified, instead. How does Skor deal with this issue?
Thanks!
The text was updated successfully, but these errors were encountered:
The default trigger that init.sh adds captures the entire row. This can be modified to only emit the unique identifier for a row. We'll add documentation for this (document the customisation of the trigger #6). When the row limit is hit, the notification is not delivered to skor so skor doesn't notify the webhook. I'm not sure about the behavior when the queue size limit is hit, but I'm guessing it should be the same, i.e, skor doesn't get the event, so it doesn't notify the webhook.
Lacks of permissions on listen/notify is a bit of a pain in Postgres. skor makes no assumptions about the validity of a notification, it merely forwards it to the webhook.
Awesome, thanks! This makes sense. In the case of the row limit getting hit, you would see the error get logged, anyway, so there's no point in Skor doing anything there, really, and impartiality wrt the validity of a notification also makes total sense. 👍🏽
👋🏽 Hello!
First, what a great project! I love Postgres' LISTEN/NOTIFY feature and am using it as a key part of a system I'm currently building.
I have two questions:
Postgres has an 8000 byte limit on message payload size, and an 8 GB queue size limit for all notifies (ref: https://www.postgresql.org/docs/9.6/static/sql-notify.html). It's possible to hit the first limit very easily with a normal-sized jsonb column, and I'm not sure how many instances out there run with less than 8 GB of memory, but in the case that either limit is reached, how does Skor deal with it? Does it just pass the error from Postgres along to the caller or crash?
Since notifications have no access control, meaning any code that can connect to your database can send notification messages, message payloads can't really be trusted. In my own system, I only use them to notify the caller that something has changed. I looked briefly at https://pgxn.org/dist/pg_message_queue/, but ultimately decided to just grab the changed row when notified, instead. How does Skor deal with this issue?
Thanks!
The text was updated successfully, but these errors were encountered: