3 ms·
Yeah, read the docs here [1] and really does not seem like this would be a good system to work with. To make something fault tolerant you have to have a side s
by cogman10 3y ago
Yeah, read the docs here [1] and really does not seem like this would be a good system to work with. To make something fault tolerant you have to have a side subscription running watching for server errors so you can resolve these conflicts when they arise.
pglogical gave you the option to determine the winner of a conflicting write (which I think is preferable). The inbuilt postgres stuff seems like it'd be rife with potential errors.
[1] https://www.postgresql.org/docs/16/logical-replication-conflicts.html https://www.postgresql.org/docs/16/logical-replication-confl...
- brianwawok 3y agoI assume you just go very basic. All updates to table X go to database Y. Don’t have all the clients slamming different databases with updates to the same stuff. Not ideal but would still help with some scale stuff.
- philjohn 3y agoOr an analytics system - spray events at whatever server, because each row is a unique record separate from the others, you get no conflicts. Benefit - if your current system with a single primary for writes is suffering and your data and use-case fits this pattern, you can increase your write throughput without scaling up.