Gregory Stark wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> 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.

No, it's a good point.

the pseudo-code might look something like

 res = enqueue_notification
 exit when res == success
end loop

That should be enough I think.



---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at


Reply via email to