Merlin Moncure wrote:
On Mon, Mar 26, 2007 at 10:30 AM, Andrew Dunstan wrote:
This feature (ability to add a message payload to a NOTIFY) is on the TODO
list and I had undertaken to implement it. However, pressure of other work
has conspired to make that difficult, and Abhijit Menon-Sen re
On Mon, Mar 26, 2007 at 10:30 AM, Andrew Dunstan wrote:
>
> This feature (ability to add a message payload to a NOTIFY) is on the TODO
> list and I had undertaken to implement it. However, pressure of other work
> has conspired to make that difficult, and Abhijit Menon-Sen recently very
> kindly o
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
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.
Well, that's an artifact of the historical implementation ... does
anyone want to argue that LISTEN sh
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> 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.
Well, that's an artifact of the historical implementation ... does
anyone want to argue that LISTEN should be cluster
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 specifi
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 g
Ühel kenal päeval, T, 2007-03-27 kell 16:13, kirjutas Hannu Krosing:
>
> 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 ?
>
> > (see earlier discussion).
>
> could you post a link to archives ?
Sorry, found it now.
Ühel kenal päeval, T, 2007-03-27 kell 07:11, kirjutas Andrew Dunstan:
>
> Hannu Krosing wrote:
> > So perhaps it Alvaros proposal can be rephrased thus:
> > "Why have the name on each message? The names are already stored in
> > listen table, just reuse numeric identifier pointing to item in that
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 shr
Hannu Krosing wrote:
Now that I think about it again, maybe we should NOT go for a
shared memory implementation after all, as we now have HOT updates and
thanks to the fact, that we have 1:1 correspondence between the backends
and
deleters in LISTEN/NOTIFY we can have much more exact DEAD-nes
Hannu Krosing wrote:
I find the feature very useful, and have even done some preliminary
design work for shared memory implementation, where each listener is
required to copy data to its own privat memory ASAP and notifier waits
in case there is not enough room in shared memory buffer.
Alas, I
Hannu Krosing wrote:
So perhaps it Alvaros proposal can be rephrased thus:
"Why have the name on each message? The names are already stored in
listen table, just reuse numeric identifier pointing to item in that
table. That gives you room for a lot more messages."
If there is no name in listen
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
... 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.
Minor comment --- I don't believe in having a separate "
Ühel kenal päeval, T, 2007-03-27 kell 11:17, kirjutas Hannu Krosing:
> Ühel kenal päeval, E, 2007-03-26 kell 11:30, kirjutas Andrew Dunstan:
> > This feature (ability to add a message payload to a NOTIFY) is on the
> > TODO list and I had undertaken to implement it. However, pressure of
> > other
Ühel kenal päeval, E, 2007-03-26 kell 11:30, kirjutas Andrew Dunstan:
> This feature (ability to add a message payload to a NOTIFY) is on the
> TODO list and I had undertaken to implement it. However, pressure of
> other work has conspired to make that difficult, and Abhijit Menon-Sen
> recently
Ühel kenal päeval, E, 2007-03-26 kell 14:07, kirjutas Tom Lane:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Why have the name on each message? Presumably names are going to be few
> > compared to the total number of messages, so maybe store the names in a
> > separate hash table and link them
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> ... 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.
Minor comment --- I don't believe in having a separate "sprinkle" of
notify-spe
"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 requi
Andrew Dunstan wrote:
>
> 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
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Why have the name on each message? Presumably names are going to be few
> compared to the total number of messages, so maybe store the names in a
> separate hash table and link them with a numeric identifier. That gives
> you room for a lot more messag
Alvaro Herrera wrote:
Andrew Dunstan wrote:
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 backe
Andrew Dunstan wrote:
> 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 th
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 agr
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.
and b) that there is broad
agreement on the general design (
This feature (ability to add a message payload to a NOTIFY) is on the
TODO list and I had undertaken to implement it. However, pressure of
other work has conspired to make that difficult, and Abhijit Menon-Sen
recently very kindly offered to help out.
Therer was some discussion of implementa
25 matches
Mail list logo
