mirror/postgresql
2
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2024-12-15 08:20:16 +08:00
Code Issues Packages Projects Releases Wiki Activity

Grammar, my boy, grammar :-(

Browse Source
This commit is contained in:
Tom Lane 1998-10-08 01:28:58 +00:00
parent af5d6b4ef6
commit f1fef841c3
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -147,16 +147,16 @@ after the transaction is completed (either committed or aborted). Again, the
reasoning is that if a notify were delivered within a transaction that was reasoning is that if a notify 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 --- but
the backend cannot "take back" a notify once it has sent it to the frontend. the backend cannot "take back" a notify once it has sent it to the frontend.
So notify events are delivered only between transactions. The upshot of this So notify events are only delivered between transactions. The upshot of this
is that applications using <command>NOTIFY</command> for real-time signaling is that applications using <command>NOTIFY</command> for real-time signaling
should try to keep their transactions short. should try to keep their transactions short.
<para> <para>
<command>NOTIFY</command> behaves rather like Unix signals in one important <command>NOTIFY</command> behaves like Unix signals in one important
respect: if the same notify name is signaled multiple times in quick respect: if the same condition name is signaled multiple times in quick
succession, recipients may get only one notify event for several executions succession, recipients may get only one notify event for several executions
of <command>NOTIFY</command>. So it is a bad idea to depend on the number of <command>NOTIFY</command>. So it is a bad idea to depend on the number
of notifies received; instead use <command>NOTIFY</command> to wake up of notifies received. Instead, use <command>NOTIFY</command> to wake up
applications that need to pay attention to something, and use a database 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 object (such as a sequence) to keep track of what happened or how many times
it happened. it happened.
@ -201,8 +201,8 @@ table name, even if syntactically valid as a name. That is no longer required.
<para> <para>
In <productname>Postgres</productname> releases prior to 6.4, the backend In <productname>Postgres</productname> releases prior to 6.4, the backend
PID delivered in a notify message is always the PID of the frontend's own PID delivered in a notify message was always the PID of the frontend's own
backend. So it is not possible to distinguish one's own notifies from other backend. So it was not possible to distinguish one's own notifies from other
clients' notifies in those earlier releases. clients' notifies in those earlier releases.
</REFSECT2> </REFSECT2>