Fix LISTEN/NOTIFY race condition reported by Laurent Birtz, by postponing

pg_listener modifications commanded by LISTEN and UNLISTEN until the end
of the current transaction.  This allows us to hold the ExclusiveLock on
pg_listener until after commit, with no greater risk of deadlock than there
was before.  Aside from fixing the race condition, this gets rid of a
truly ugly kludge that was there before, namely having to ignore
HeapTupleBeingUpdated failures during NOTIFY.  There is a small potential
incompatibility, which is that if a transaction issues LISTEN or UNLISTEN
and then looks into pg_listener before committing, it won't see any resulting
row insertion or deletion, where before it would have.  It seems unlikely
that anyone would be depending on that, though.

This patch also disallows LISTEN and UNLISTEN inside a prepared transaction.
That case had some pretty undesirable properties already, such as possibly
allowing pg_listener entries to be made for PIDs no longer present, so
disallowing it seems like a better idea than trying to maintain the behavior.

doc/src/sgml/ref/prepare_transaction.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/ref/prepare_transaction.sgml,v 1.6 2007/09/11 00:06:41 tgl Exp $
+$PostgreSQL: pgsql/doc/src/sgml/ref/prepare_transaction.sgml,v 1.7 2008/03/12 20:11:45 tgl Exp $
 PostgreSQL documentation
 -->
 
@@ -88,8 +88,10 @@ PREPARE TRANSACTION <replaceable class="PARAMETER">transaction_id</replaceable>
 
   <para>
    It is not currently allowed to <command>PREPARE</> a transaction that
-   has executed any operations involving temporary tables or
-   created any cursors <literal>WITH HOLD</>.  Those features are too tightly
+   has executed any operations involving temporary tables,
+   created any cursors <literal>WITH HOLD</>, or executed
+   <command>LISTEN</> or <command>UNLISTEN</>.
+   Those features are too tightly
    tied to the current session to be useful in a transaction to be prepared.
   </para>