News for hackers. Stuff that matters.

ciminelli

Re:Show HN: Safe Data Changes in PostgreSQL on Friday March 10, 2023 @12:47PM (#35098073)
How would you want to actually look at the database diff? Just a summary view of rows that were changed given a certain time period?
Re:Show HN: Safe Data Changes in PostgreSQL on Thursday March 09, 2023 @02:43PM (#35085650)
We were looking at tooling for snapshotting production data for testing purposes, that use case is interesting to have the diff view based on changes happening from application actions. Would you use it for testing changes or more for debugging production issues?

Show HN: Safe Data Changes in PostgreSQL

https://github.com/inqueryio/inquery

Hi HN, we're excited to share our open source tool with the community! We previously posted[0] here with the tagline “real-time events for Postgres”. But after feedback from early users and the community, we’ve shifted our focus to working on tooling for manual database changes.We've consistently heard teams describe challenges with the way manual data updates are handled. Seemingly every...

( Read More... | 17 comments | 2 points | on HN )
The trigger will break the message out into chunks of <8k bytes and send them as separate messages with a unique ID and then an EOF once the message is complete. Planning on releasing this change in the next few days.
We're working on and looking into a few different solutions right now:

1. Split the payload into chunks of 8k bytes and send them as separate messages to the server (in progress, will be released in the next few days).

2. Use a new table as an event queue where the trigger will write data and our server will consume it. We do want to incorporate an event queue soon so this approach would solve for that as long as users are ok with the system writing to a new table.

3. Use one of the Postgres logs to stream events instead of LISTEN/NOTIFY.

Let me know if you have thoughts on any of these approaches!

No extensions are required since we're using LISTEN/NOTIFY in the triggers! We haven't tested full backwards compatibility with older versions but are planning on doing that soon.
Yes and great question, right now we are limited to 8000 bytes but are working on an update to handle large payloads via chunking—stay tuned!