5 ms·
And how do you get back in sync if the client that did the LISTEN, crashes and has to be restarted?
by gnud 10y ago
And how do you get back in sync if the client that did the LISTEN, crashes and has to be restarted?
- openasocket 10y agoUsing NOTIFY puts the data into a message queue, so messages will just hold there until your client listens again. Eventually it the channel queue will be filled up (8GB by default), at which point the NOTIFY will fail. https://www.postgresql.org/docs/9.0/static/sql-notify.html https://www.postgresql.org/docs/9.0/static/sql-notify.html
- gnud 10y agoI don't think it will? When the client restarts, it will create a new session with the postgres server. This new session will not receive messages that are queued for the old session.
- openasocket 10y agoAh, yes, I think you're right. I suppose you would want to represent a message queue using a table and have your daemon process remove things from the table as it adds things to elastic search. That way if the daemon crashes the events will just continue to buffer.
- yummyfajitas 10y agoSame way you handle redundancy in general. You'll need multiple clients listening, and some sort of consensus algorithm to get them back into sync when one restarts. One simple way (which involves doing double work) would be to have 2 clients, both of which listen to postgres and push to elastic search. Each sync will happen twice, but the sync will only fail to occur if both go down.