"Andrew Dunstan" <andrew@dunslane.net> writes:
>>> 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.
Keep in mind that the usual place you run into problems with this type of
buffering is where you have two processes talking to each other. Say a
producer-consumer type of design. You want to be sure you never deadlock
with each process waiting for the other to consume a notification.
I don't think this is a problem in this case because it just means the state
you enter when you're blocked waiting for your buffer to have free space MUST
be amongst the times you call CHECK_FOR_NOTIFICATIONS(). If you didn't plan to
have this local storage in the backend it would be difficult to guarantee that
clients would handle this situation correctly.
Perhaps that was obvious already. If so, sorry for worrying for nothing.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com
