From d1e027221d0243b7b57eabb0e482923dd7d1c8eb Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Tue, 16 Feb 2010 22:34:57 +0000 Subject: Replace the pg_listener-based LISTEN/NOTIFY mechanism with an in-memory queue. In addition, add support for a "payload" string to be passed along with each notify event. This implementation should be significantly more efficient than the old one, and is also more compatible with Hot Standby usage. There is not yet any facility for HS slaves to receive notifications generated on the master, although such a thing is possible in future. Joachim Wieland, reviewed by Jeff Davis; also hacked on by me. --- doc/src/sgml/ref/listen.sgml | 38 +++++++++---- doc/src/sgml/ref/notify.sgml | 121 +++++++++++++++++++++++++++++------------ doc/src/sgml/ref/unlisten.sgml | 19 ++++--- 3 files changed, 125 insertions(+), 53 deletions(-) (limited to 'doc/src/sgml/ref') diff --git a/doc/src/sgml/ref/listen.sgml b/doc/src/sgml/ref/listen.sgml index 93ca74c5722..57577c1f6ac 100644 --- a/doc/src/sgml/ref/listen.sgml +++ b/doc/src/sgml/ref/listen.sgml @@ -1,5 +1,5 @@ @@ -21,7 +21,7 @@ PostgreSQL documentation -LISTEN name +LISTEN channel @@ -30,24 +30,23 @@ LISTEN name LISTEN registers the current session as a - listener on the notification condition name. + listener on the notification channel named channel. If the current session is already registered as a listener for - this notification condition, nothing is done. + this notification channel, nothing is done. Whenever the command NOTIFY name is invoked, either + class="PARAMETER">channel is invoked, either by this session or another one connected to the same database, all - the sessions currently listening on that notification condition are + the sessions currently listening on that notification channel are notified, and each will in turn notify its connected client - application. See the discussion of NOTIFY for - more information. + application. - A session can be unregistered for a given notify condition with the + A session can be unregistered for a given notification channel with the UNLISTEN command. A session's listen registrations are automatically cleared when the session ends. @@ -78,16 +77,31 @@ LISTEN name - name + channel - Name of a notify condition (any identifier). + Name of a notification channel (any identifier). + + Notes + + + LISTEN takes effect at transaction commit. + If LISTEN or UNLISTEN is executed + within a transaction that later rolls back, the set of notification + channels being listened to is unchanged. + + + A transaction that has executed LISTEN cannot be + prepared for two-phase commit. + + + Examples diff --git a/doc/src/sgml/ref/notify.sgml b/doc/src/sgml/ref/notify.sgml index 563fbbe9638..b612bb4cb2a 100644 --- a/doc/src/sgml/ref/notify.sgml +++ b/doc/src/sgml/ref/notify.sgml @@ -1,5 +1,5 @@ @@ -21,7 +21,7 @@ PostgreSQL documentation -NOTIFY name +NOTIFY channel [ , payload ] @@ -29,35 +29,39 @@ NOTIFY name Description - The NOTIFY command sends a notification event to each - client application that has previously executed - LISTEN name - for the specified notification name in the current database. + The NOTIFY command sends a notification event together + with an optional payload string to each client application that + has previously executed + LISTEN channel + for the specified channel name in the current database. - NOTIFY provides a simple form of signal or + NOTIFY provides a simple interprocess communication mechanism for a collection of processes accessing the same PostgreSQL database. - Higher-level mechanisms can be built by using tables in the database to - pass additional data (beyond a mere notification name) from notifier to - listener(s). + A payload string can be sent along with the notification, and + higher-level mechanisms for passing structured data can be built by using + tables in the database to pass additional data from notifier to listener(s). - The information passed to the client for a notification event includes the notification - name and the notifying session's server process PID. It is up to the - database designer to define the notification names that will be used in a given - database and what each one means. + The information passed to the client for a notification event includes the + notification channel + name, the notifying session's server process PID, and the + payload string, which is an empty string if it has not been specified. - Commonly, the notification name is the same as the name of some table in + It is up to the database designer to define the channel names that will + be used in a given database and what each one means. + Commonly, the channel name is the same as the name of some table in the database, and the notify event essentially means, I changed this table, take a look at it to see what's new. But no such association is enforced by the NOTIFY and LISTEN commands. For - example, a database designer could use several different notification names - to signal different sorts of changes to a single table. + example, a database designer could use several different channel names + to signal different sorts of changes to a single table. Alternatively, + the payload string could be used to differentiate various cases. @@ -89,19 +93,22 @@ NOTIFY name - NOTIFY behaves like Unix signals in one important - respect: if the same notification name is signaled multiple times in quick - succession, recipients might get only one notification event for several executions - of NOTIFY. So it is a bad idea to depend on the number - of notifications received. Instead, use NOTIFY to wake up - applications that need to pay attention to something, and use a database - object (such as a sequence) to keep track of what happened or how many times - it happened. + If the same channel name is signaled multiple times from the same + transaction with identical payload strings, the + database server can decide to deliver a single notification only. + On the other hand, notifications with distinct payload strings will + always be delivered as distinct notifications. Similarly, notifications from + different transactions will never get folded into one notification. + Except for dropping later instances of duplicate notifications, + NOTIFY guarantees that notifications from the same + transaction get delivered in the order they were sent. It is also + guaranteed that messages from different transactions are delivered in + the order in which the transactions committed. It is common for a client that executes NOTIFY - to be listening on the same notification name itself. In that case + to be listening on the same notification channel itself. In that case it will get back a notification event, just like all the other listening sessions. Depending on the application logic, this could result in useless work, for example, reading a database table to @@ -111,12 +118,7 @@ NOTIFY name notification event message) is the same as one's own session's PID (available from libpq). When they are the same, the notification event is one's own work bouncing - back, and can be ignored. (Despite what was said in the preceding - paragraph, this is a safe technique. - PostgreSQL keeps self-notifications - separate from notifications arriving from other sessions, so you - cannot miss an outside notification by ignoring your own - notifications.) + back, and can be ignored. @@ -125,16 +127,61 @@ NOTIFY name - name + channel - Name of the notification to be signaled (any identifier). + Name of the notification channel to be signaled (any identifier). + + + + + payload + + + The payload string to be communicated along with the + notification. This string must be shorter than 8000 bytes, and + is treated as text. + (If binary data or large amounts of information need to be communicated, + it's best to put it in a database table and send the key of the record.) + + Notes + + + pg_notify + + + + To send a notification you can also use the function + pg_notify(text, + text). The function takes the channel name as the + first argument and the payload as the second. The function is much easier + to use than the NOTIFY command if you need to work with + non-constant channel names and payloads. + + + There is a queue that holds notifications that have been sent but not + yet processed by all listening sessions. If this queue becomes full, + transactions calling NOTIFY will fail at commit. + The queue is quite large (8GB in a standard installation) and should be + sufficiently sized for almost every use case. However, no cleanup can take + place if a session executes LISTEN and then enters a + transaction for a very long time. Once the queue is half full you will see + warnings in the log file pointing you to the session that is preventing + cleanup. In this case you should make sure that this session ends its + current transaction so that cleanup can proceed. + + + A transaction that has executed NOTIFY cannot be + prepared for two-phase commit. + + + Examples @@ -146,6 +193,12 @@ NOTIFY name LISTEN virtual; NOTIFY virtual; Asynchronous notification "virtual" received from server process with PID 8448. +NOTIFY virtual, 'This is the payload'; +Asynchronous notification "virtual" with payload "This is the payload" received from server process with PID 8448. + +LISTEN foo; +SELECT pg_notify('fo' || 'o', 'pay' || 'load'); +Asynchronous notification "foo" with payload "payload" received from server process with PID 14728. diff --git a/doc/src/sgml/ref/unlisten.sgml b/doc/src/sgml/ref/unlisten.sgml index 7cdd7394cb9..9e22ea4edc4 100644 --- a/doc/src/sgml/ref/unlisten.sgml +++ b/doc/src/sgml/ref/unlisten.sgml @@ -1,5 +1,5 @@ @@ -21,7 +21,7 @@ PostgreSQL documentation -UNLISTEN { name | * } +UNLISTEN { channel | * } @@ -33,8 +33,8 @@ UNLISTEN { name | * } registration for NOTIFY events. UNLISTEN cancels any existing registration of the current PostgreSQL session as a - listener on the notification name. The special wildcard + listener on the notification channel named channel. The special wildcard * cancels all listener registrations for the current session. @@ -52,10 +52,10 @@ UNLISTEN { name | * } - name + channel - Name of a notification (any identifier). + Name of a notification channel (any identifier). @@ -83,6 +83,11 @@ UNLISTEN { name | * } At the end of each session, UNLISTEN * is automatically executed. + + + A transaction that has executed UNLISTEN cannot be + prepared for two-phase commit. + @@ -100,7 +105,7 @@ Asynchronous notification "virtual" received from server process with PID 8448. Once UNLISTEN has been executed, further NOTIFY - commands will be ignored: + messages will be ignored: UNLISTEN virtual; -- cgit v1.2.3