Home • Explore • Blog • CI
☰



postgresql
3rd chunk of `doc/src/sgml/ref/notify.sgml`
bce05e8f45b5889639c85e9a1ccd81d0730d29544c54751d000000010000081c
 useless work, for example, reading a database table to
   find the same updates that that session just wrote out.  It is
   possible to avoid such extra work by noticing whether the notifying
   session's server process <acronym>PID</acronym> (supplied in the
   notification event message) is the same as one's own session's
   <acronym>PID</acronym> (available from <application>libpq</application>).  When they
   are the same, the notification event is one's own work bouncing
   back, and can be ignored.
  </para>
 </refsect1>

 <refsect1>
  <title>Parameters</title>

  <variablelist>
   <varlistentry>
    <term><replaceable class="parameter">channel</replaceable></term>
    <listitem>
     <para>
      Name of the notification channel to be signaled (any identifier).
     </para>
    </listitem>
   </varlistentry>
   <varlistentry>
    <term><replaceable class="parameter">payload</replaceable></term>
    <listitem>
     <para>
      The <quote>payload</quote> string to be communicated along with the
      notification.  This must be specified as a simple string literal.
      In the default configuration it must be shorter than 8000 bytes.
      (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.)
     </para>
    </listitem>
   </varlistentry>
  </variablelist>
 </refsect1>

 <refsect1>
  <title>Notes</title>

  <para>
   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 <command>NOTIFY</command> 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 <command>LISTEN</command> 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
Title: NOTIFY: Avoiding Redundant Work, Parameters, and Queue Management
Summary
A client executing NOTIFY can also listen on the same channel and receive a notification event, potentially leading to redundant work. This can be avoided by checking if the notifying session's PID matches the client's PID and ignoring the notification if they are the same. The NOTIFY command takes two parameters: 'channel', the name of the notification channel, and 'payload', the string to be communicated. The payload should be a simple string literal, less than 8000 bytes in the default configuration. A queue holds notifications, and if this queue becomes full, transactions calling NOTIFY will fail at commit. Long-lived LISTEN transactions can prevent queue cleanup, leading to warnings in the log file.