</para>

      <para>
       If <function>PQcancelStart</function> succeeds, the next stage
       is to poll <application>libpq</application> so that it can proceed with
       the cancel connection sequence.
       Use <xref linkend="libpq-PQcancelSocket"/> to obtain the descriptor of the
       socket underlying the database connection.
       (Caution: do not assume that the socket remains the same
       across <function>PQcancelPoll</function> calls.)
       Loop thus: If <function>PQcancelPoll(cancelConn)</function> last returned
       <symbol>PGRES_POLLING_READING</symbol>, wait until the socket is ready to
       read (as indicated by <function>select()</function>,
       <function>poll()</function>, or similar system function).
       Then call <function>PQcancelPoll(cancelConn)</function> again.
       Conversely, if <function>PQcancelPoll(cancelConn)</function> last returned
       <symbol>PGRES_POLLING_WRITING</symbol>, wait until the socket is ready
       to write, then call <function>PQcancelPoll(cancelConn)</function> again.
       On the first iteration, i.e., if you have yet to call
       <function>PQcancelPoll(cancelConn)</function>, behave as if it last returned
       <symbol>PGRES_POLLING_WRITING</symbol>.  Continue this loop until
       <function>PQcancelPoll(cancelConn)</function> returns
       <symbol>PGRES_POLLING_FAILED</symbol>, indicating the connection procedure
       has failed, or <symbol>PGRES_POLLING_OK</symbol>, indicating cancel
       request was successfully dispatched.
      </para>

      <para>
       Successful dispatch of the cancellation is no guarantee that the request
       will have any effect, however. If the cancellation is effective, the
       command being canceled will terminate early and return an error result.
       If the cancellation fails (say, because the server was already done
       processing the command), then there will be no visible result at all.
      </para>

      <para>
       At any time during connection, the status of the connection can be
       checked by calling <xref linkend="libpq-PQcancelStatus"/>.
       If this call returns <symbol>CONNECTION_BAD</symbol>, then
       the cancel procedure has failed; if the call returns
       <symbol>CONNECTION_OK</symbol>, then cancel request was
       successfully dispatched.
       Both of these states are equally detectable from the return value of
       <function>PQcancelPoll</function>, described above.
       Other states might also occur during (and only during) an asynchronous
       connection procedure.
       These indicate the current stage of the connection procedure and might
       be useful to provide feedback to the user for example.
       These statuses are:

       <variablelist>
        <varlistentry id="libpq-cancel-connection-allocated">
         <term><symbol>CONNECTION_ALLOCATED</symbol></term>
         <listitem>
          <para>
           Waiting for a call to <xref linkend="libpq-PQcancelStart"/> 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.