zlacker

[parent] [thread] 3 comments
1. anonu+(OP)[view] [source] 2021-12-18 00:23:00
Thanks for the great blog post - still relevant after a few years!

> statement_timeout=(a few days)

wouldnt you want this to be a few seconds or minutes? Maybe I miss the point of setting this to days...

replies(1): >>colinc+n
2. colinc+n[view] [source] 2021-12-18 00:26:27
>>anonu+(OP)
Didn't want to deal with ramifications of statement timeouts in a complex system, the failure mode mentioned (queue filling up) happened on the scale of 6 weeks, so it was very cheap operationally to set this timeout to some high value.
replies(1): >>runeks+091
◧◩
3. runeks+091[view] [source] [discussion] 2021-12-18 13:48:24
>>colinc+n
So, just to make sure I understand correctly: notifications are delivered while the notification queue size is increasing (due to the transaction holding a lock), and it doesn’t become a problem until the queue size reaches its maximum, at which point it causes dropped notifications?

But the queue grows precisely because some notifications aren’t getting delivered, right?

replies(1): >>colinc+kv1
◧◩◪
4. colinc+kv1[view] [source] [discussion] 2021-12-18 16:36:28
>>runeks+091
Since it's pub/sub, you just need one misbehaving client that LISTENs in a transaction to have problems, the other clients can still receive and process the NOTIFY event
[go to top]