Tom Lane wrote:
Hannu Krosing <[EMAIL PROTECTED]> writes:
Ühel kenal päeval, T, 2007-03-27 kell 07:11, kirjutas Andrew Dunstan:
Er, what listen table?
At least the list of which backends listen to which events should be
also in shared mem.
No, the intent is specifically that there will be *no* such global
structure. All it does is add complexity, not to mention make it
harder to size shared memory.
How else would we know how many copies to make for each backend or when
we can release the memory in case we make one copy ?
The proposed design is essentially a clone of the sinval messaging
system, which does not need to know either of those and does not make
"one copy per backend". There's one copy, period.
Further design notes:
What we will need to keep track of (a la sinval) is a queue pointer per
backend. I think we can add an optimization to that by keeping a count
of events listened to per backend, so that we only wake up active
listeners. For non listeners we can just catch them up without bothering
to wake them. This will help to avoid the potential for a "thundering
herd" effect that has apparently bothered some people.
We'll also need to store the database id along with the event name and
message, since pg_listener is per db rather than per cluster.
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
