ciminelli

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?

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?

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!