Re: notification payloads - Mailing list pgsql-hackers
From | Hannu Krosing |
---|---|
Subject | Re: notification payloads |
Date | |
Msg-id | 1174984724.3701.21.camel@localhost.localdomain Whole thread Raw |
In response to | Re: notification payloads (Hannu Krosing <hannu@skype.net>) |
Responses |
Re: notification payloads
|
List | pgsql-hackers |
Ü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 work has conspired to make that difficult, and Abhijit Menon-Sen > > recently very kindly offered to help out. > > > > Therer was some discussion of implementation late last year here: > > http://groups.google.com/group/pgsql.hackers/browse_frm/thread/e63a5ac43e2508ce/ce47016235bd5a62?tvc=1&q=notify+payload&hl=en#ce47016235bd5a62 > > > > However, in various pieces of off-list discussion it appears that there > > is some opposition either to the design or to the feature itself. What > > is more, there will clearly be vigorous opposition to any implementation > > which does NOT remove the use of pg_listener (which I understand and I > > think largely agree with). > > > > 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 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). > > Please speak up or forever .... 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-ness conditions and can reuse space even in presence of long-running transactions. IOW, once we have deleted the message, we can be sure that no other backend will ever be interested in that row. That means it may be possible to use a design similar to the one I just sent and just make the tables not wal-logged and have dead space reused in HOT-like manner. Straight HOT wil not be useful here, as usage is INSERT/DELETE instead of UPDATE, but similar principles, including heap space and index pointer reuse could probably be done. -- ---------------- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com
pgsql-hackers by date: