listen/notify argument (old topic revisited)

listen/notify argument (old topic revisited)

Post by Tom La » Fri, 05 Jul 2002 14:44:42

>> Right.  But we play similar games already with the existing SI buffer,
>> to wit:
> It means a full seq scan over pointers ;)

I have not seen any indication that the corresponding scan in the SI
code is a bottleneck --- and that has to scan over *all* backends,
without even the opportunity to skip those that aren't LISTENing.

Quote:> OK. Now, how will we introduce transactional behaviour to this scheme ?

It's no different from before --- notify messages don't get into the
buffer at all, until they're committed.  See my earlier response to Neil.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?


1. listen/notify argument (old topic revisited)

A while ago, I started a small discussion about passing arguments to a NOTIFY
so that the listening backend could get more information about the event.

There wasn't exactly a consensus from what I understand, but the last thing I
remember is that someone intended to speed up the notification process by
storing the events in shared memory segments (IIRC this was Tom's idea). That
would create a remote possibility of a spurious notification, but the idea is
that the listening application can check the status and determine what

I looked at the TODO, but I couldn't find anything, nor could I find anything
in the docs.

Is someone still interested in implementing this feature? Are there still
people who disagree with the above implementation strategy?


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

2. Pre-Imaging schemes?

3. LISTEN/NOTIFY benchmarks?

4. scale of NUMERIC arguments to a stored procedure


6. HELP! onbar restore problems - Unable to write restored data to the database: could not fork server connection.

7. NOTIFY/LISTEN Using Embedded SQL (ecpg)

8. Trailing Zeros are being stripped

9. LISTEN/NOTIFY benchmarks?

10. problem with notify/listen

11. Synchronous LISTEN/NOTIFY?


13. Notify argument?