Dave Page wrote:
Andrew Dunstan wrote:

So, before an investment of any more time is made by either Abhijit or myself, I would like to get confirmation that a) there is broad agreement on the desirability of the feature

Yes, absolutely desirable.

good ;-)

and b) that there is broad agreement on the general design (i.e. to use a circular buffer in shared memory, of configurable size, to hold the outstanding message queue).

Would it spill out to disk and expand (and shrink again) as required? Loss of notifications should not occur imho.

No loss, but, per previous discussion, it would block and try to get other backends to collect their outstanding notifications.

Let's say we provide 100Kb for this (which is not a heck of a lot) , that the average notification might be, say, 40 bytes of name plus 60 bytes of message. Then we have room for about 1000 messages in the queue. This would get ugly only if backend presumably in the middle of some very long transaction, refused to pick up its messages despite prodding. But ISTM that means we just need to pick a few strategic spots that will call CHECK_FOR_NOTIFICATIONS() even in the middle of a transaction and store them locally.



---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


Reply via email to