Thats good to know. Are there some standard patterns or best practices I should follow when using messaging and with listen/notify?
On Sat, Jul 11, 2020 at 1:44 PM Brian Dunavant <dunav...@gmail.com> wrote: > One aspect is if there is no one listening when a notify happens, the > message is lost (e.g. no durability). If this is important to you, it can > be addressed by writing the messages to a table as well when you NOTIFY, > and the listener deletes messages after they are processed. On connection > the listener can query the table to catch up on any missed messages, or > messages that were mid-process during a crash. This is trickier with more > than one listener. This isn't a whole lot more efficient than just using > the table alone, but it saves you from having to poll so better response > times. > > On Sat, Jul 11, 2020 at 8:58 AM Rita <rmorgan...@gmail.com> wrote: > >> I am investigating various pub/sub tools such as ActiveMQ, Rabbit, Redis, >> etc.I came across Postgresql Listen/Notify and was easily able to write >> code to listen to messages. For the people who have been using this for a >> while: what are its downsides, things to consider when writing good code >> that use pub/sub, how do you deal with large messages, can I have >> subscribers listen to replica nodes? >> >> Thanks >> -- >> --- Get your facts first, then you can distort them as you please.-- >> > -- --- Get your facts first, then you can distort them as you please.--
