or
           <xref linkend="libpq-PQcancelBlocking"/>, to actually open the
           socket. This is the connection state right after
           calling <xref linkend="libpq-PQcancelCreate"/>
           or <xref linkend="libpq-PQcancelReset"/>. No connection to the
           server has been initiated yet at this point. To actually start
           sending the cancel request use <xref linkend="libpq-PQcancelStart"/> or
           <xref linkend="libpq-PQcancelBlocking"/>.
          </para>
         </listitem>
        </varlistentry>

        <varlistentry id="libpq-cancel-connection-started">
         <term><symbol>CONNECTION_STARTED</symbol></term>
         <listitem>
          <para>
           Waiting for connection to be made.
          </para>
         </listitem>
        </varlistentry>

        <varlistentry id="libpq-cancel-connection-made">
         <term><symbol>CONNECTION_MADE</symbol></term>
         <listitem>
          <para>
           Connection OK; waiting to send.
          </para>
         </listitem>
        </varlistentry>

        <varlistentry id="libpq-cancel-connection-awaiting-response">
         <term><symbol>CONNECTION_AWAITING_RESPONSE</symbol></term>
         <listitem>
          <para>
           Waiting for a response from the server.
          </para>
         </listitem>
        </varlistentry>

        <varlistentry id="libpq-cancel-connection-ssl-startup">
         <term><symbol>CONNECTION_SSL_STARTUP</symbol></term>
         <listitem>
          <para>
           Negotiating SSL encryption.
          </para>
         </listitem>
        </varlistentry>

        <varlistentry id="libpq-cancel-connection-gss-startup">
         <term><symbol>CONNECTION_GSS_STARTUP</symbol></term>
         <listitem>
          <para>
           Negotiating GSS encryption.
          </para>
         </listitem>
        </varlistentry>
       </variablelist>

       Note that, although these constants will remain (in order to maintain
       compatibility), an application should never rely upon these occurring in a
       particular order, or at all, or on the status always being one of these
       documented values. An application might do something like this:
<programlisting>
switch(PQcancelStatus(conn))
{
        case CONNECTION_STARTED:
            feedback = "Connecting...";
            break;

        case CONNECTION_MADE:
            feedback = "Connected to server...";
            break;
.
.
.
        default:
            feedback = "Connecting...";
}
</programlisting>
      </para>

      <para>
       The <literal>connect_timeout</literal> connection parameter is ignored
       when using <function>PQcancelPoll</function>; it is the application's
       responsibility to decide whether an excessive amount of time has elapsed.
       Otherwise, <function>PQcancelStart</function> followed by a
       <function>PQcancelPoll</function> loop is equivalent to
       <xref linkend="libpq-PQcancelBlocking"/>.
      </para>

     </listitem>
    </varlistentry>

    <varlistentry id="libpq-PQcancelStatus">
     <term><function>PQcancelStatus</function><indexterm><primary>PQcancelStatus</primary></indexterm></term>

     <listitem>
      <para>
       Returns the status of the cancel connection.
<synopsis>
ConnStatusType PQcancelStatus(const PGcancelConn *cancelConn);
</synopsis>
      </para>

      <para>
       The status can be one of a number of values.  However, only three of
       these are seen outside of an asynchronous cancel procedure:
       <symbol>CONNECTION_ALLOCATED</symbol>,
       <symbol>CONNECTION_OK</symbol> and
       <symbol>CONNECTION_BAD</symbol>. The initial state of a
       <function>PGcancelConn</function> that's successfully created using
       <xref linkend="libpq-PQcancelCreate"/> is <symbol>CONNECTION_ALLOCATED</symbol>.
       A cancel request that was successfully dispatched
       has the status <symbol>CONNECTION_OK</symbol>.  A failed
       cancel attempt is signaled by