Re: notification payloads

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.

cheers

andrew