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?
Well, my main use case would be to speed up project onboarding where I can play around with the app from user perspective and check how my actions impact database... Could help cutting through a lot of frontend/backend layers and just focus on raw data.
If you have multiple DB snapshots and WAL enabled, theoretically you could inspect the log to see what happened inbetween. There's pg_xlogdump for that but I think it will output very raw data...
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.
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.
