corresponds to the first host name,
       the second <literal>hostaddr</literal> corresponds to the second host name, and so
       forth. As an exception, if only one <literal>port</literal> is specified, it
       applies to all the hosts.
     </para>

     <para>
       In the connection URI format, you can list multiple <literal>host:port</literal> pairs
       separated by commas in the <literal>host</literal> component of the URI.
     </para>

     <para>
       In either format, a single host name can translate to multiple network
       addresses. A common example of this is a host that has both an IPv4 and
       an IPv6 address.
     </para>

     <para>
       When multiple hosts are specified, or when a single host name is
       translated to multiple addresses,  all the hosts and addresses will be
       tried in order, until one succeeds. If none of the hosts can be reached,
       the connection fails. If a connection is established successfully, but
       authentication fails, the remaining hosts in the list are not tried.
     </para>

     <para>
       If a password file is used, you can have different passwords for
       different hosts. All the other connection options are the same for every
       host in the list; it is not possible to e.g., specify different
       usernames for different hosts.
     </para>
   </sect3>
  </sect2>

  <sect2 id="libpq-paramkeywords">
   <title>Parameter Key Words</title>

   <para>
    The currently recognized parameter key words are:

    <variablelist>
     <varlistentry id="libpq-connect-host" xreflabel="host">
      <term><literal>host</literal></term>
      <listitem>
       <para>
        Name of host to connect to.<indexterm><primary>host
        name</primary></indexterm> If a host name looks like an absolute path
        name, it specifies Unix-domain communication rather than TCP/IP
        communication; the value is the name of the directory in which the
        socket file is stored.  (On Unix, an absolute path name begins with a
        slash.  On Windows, paths starting with drive letters are also
        recognized.)  If the host name starts with <literal>@</literal>, it is
        taken as a Unix-domain socket in the abstract namespace (currently
        supported on Linux and Windows).
        The default behavior when <literal>host</literal> is not
        specified, or is empty, is to connect to a Unix-domain
        socket<indexterm><primary>Unix domain socket</primary></indexterm> in
        <filename>/tmp</filename> (or whatever socket directory was specified
        when <productname>PostgreSQL</productname> was built).  On Windows,
        the default is to connect to <literal>localhost</literal>.
       </para>
       <para>
        A comma-separated list of host names is also accepted, in which case
        each host name in the list is tried in order; an empty item in the
        list selects the default behavior as explained above. See
        <xref linkend="libpq-multiple-hosts"/> for details.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="libpq-connect-hostaddr" xreflabel="hostaddr">
      <term><literal>hostaddr</literal></term>
      <listitem>
       <para>
        Numeric IP address of host to connect to.  This should be in the
        standard IPv4 address format, e.g., <literal>172.28.40.9</literal>.  If
        your machine supports IPv6, you can also use those addresses.
        TCP/IP communication is
        always used when a nonempty string is specified for this parameter.
        If this parameter is not specified, the value of <literal>host</literal>
        will be looked up to find the corresponding IP address &mdash; or, if
        <literal>host</literal> specifies an IP address, that value will be
        used directly.
       </para>

       <para>
        Using <literal>hostaddr</literal> allows the
        application to avoid a host name look-up, which might be important
        in