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
loop
res = enqueue_notification
collect_my_messages
exit when res == success
send_out_signal
sleep_a_bit
end loop
That should be enough I think.
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
