database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-12-18 05:01:01 +03:00
Code Activity

More minor updates and copy-editing.

Browse Source
This commit is contained in:
Tom Lane
2005-01-04 00:39:53 +00:00
parent 246be304a5
commit 4e94ea9fc9
37 changed files with 571 additions and 413 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
doc/src/sgml/ref/notify.sgml
View File

@@ -1,5 +1,5 @@
<!--
$PostgreSQL: pgsql/doc/src/sgml/ref/notify.sgml,v 1.26 2003/11/29 19:51:39 pgsql Exp $
$PostgreSQL: pgsql/doc/src/sgml/ref/notify.sgml,v 1.27 2005/01/04 00:39:53 tgl Exp $
PostgreSQL documentation
-->
@@ -34,6 +34,15 @@ NOTIFY <replaceable class="PARAMETER">name</replaceable>
for the specified notification name in the current database.
</para>
<para>
<command>NOTIFY</command> provides a simple form of signal or
interprocess communication mechanism for a collection of processes
accessing the same <productname>PostgreSQL</productname> 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).
</para>
<para>
The information passed to the client for a notification event includes the notification
name and the notifying session's server process <acronym>PID</>. It is up to the
@@ -50,15 +59,6 @@ NOTIFY <replaceable class="PARAMETER">name</replaceable>
to signal different sorts of changes to a single table.
</para>
<para>
<command>NOTIFY</command> provides a simple form of signal or
interprocess communication mechanism for a collection of processes
accessing the same <productname>PostgreSQL</productname> 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).
</para>
<para>
When <command>NOTIFY</command> is used to signal the occurrence of changes
to a particular table, a useful programming technique is to put the
@@ -79,7 +79,8 @@ NOTIFY <replaceable class="PARAMETER">name</replaceable>
the notification event will not be delivered to its connected client until just
after the transaction is completed (either committed or aborted). Again, the
reasoning is that if a notification were delivered within a transaction that was
later aborted, one would want the notification to be undone somehow---but
later aborted, one would want the notification to be undone somehow &mdash;
but
the server cannot <quote>take back</quote> a notification once it has sent it to the client.
So notification events are only delivered between transactions. The upshot of this
is that applications using <command>NOTIFY</command> for real-time signaling