<filename>pg_hba.conf</filename> file is read on start-up and when
   the main server process receives a
   <systemitem>SIGHUP</systemitem><indexterm><primary>SIGHUP</primary></indexterm>
   signal. If you edit the file on an
   active system, you will need to signal the postmaster
   (using <literal>pg_ctl reload</literal>, calling the SQL function
   <function>pg_reload_conf()</function>, or using <literal>kill
   -HUP</literal>) to make it re-read the file.
  </para>

  <note>
   <para>
    The preceding statement is not true on Microsoft Windows: there, any
    changes in the <filename>pg_hba.conf</filename> file are immediately
    applied by subsequent new connections.
   </para>
  </note>

  <para>
   The system view
   <link linkend="view-pg-hba-file-rules"><structname>pg_hba_file_rules</structname></link>
   can be helpful for pre-testing changes to the <filename>pg_hba.conf</filename>
   file, or for diagnosing problems if loading of the file did not have the
   desired effects.  Rows in the view with
   non-null <structfield>error</structfield> fields indicate problems in the
   corresponding lines of the file.
  </para>

  <para>
   The general format of the <filename>pg_hba.conf</filename> file is
   a set of records, one per line. Blank lines are ignored, as is any
   text after the <literal>#</literal> comment character.
   A record can be continued onto the next line by ending the line with
   a backslash. (Backslashes are not special except at the end of a line.)
   A record is made
   up of a number of fields which are separated by spaces and/or tabs.
   Fields can contain white space if the field value is double-quoted.
   Quoting one of the keywords in a database, user, or address field (e.g.,
   <literal>all</literal> or <literal>replication</literal>) makes the word lose its special
   meaning, and just match a database, user, or host with that name.
   Backslash line continuation applies even within quoted text or comments.
  </para>

  <para>
   Each authentication record specifies a connection type, a client IP address
   range (if relevant for the connection type), a database name, a user name,
   and the authentication method to be used for connections matching
   these parameters. The first record with a matching connection type,
   client address, requested database, and user name is used to perform
   authentication. There is no <quote>fall-through</quote> or
   <quote>backup</quote>: if one record is chosen and the authentication
   fails, subsequent records are not considered. If no record matches,
   access is denied.
  </para>

  <para>
   Each record can be an include directive or an authentication record.
   Include directives specify files that can be included, that contain
   additional records. The records will be inserted in place of the
   include directives. Include directives only contain two fields:
   <literal>include</literal>, <literal>include_if_exists</literal> or
   <literal>include_dir</literal> directive and the file or directory to be
   included. The file or directory can be a relative or absolute path, and can
   be double-quoted.  For the <literal>include_dir</literal> form, all files
   not starting with a <literal>.</literal> and ending with
   <literal>.conf</literal> will be included. Multiple files within an include
   directory are processed in file name order (according to C locale rules,
   i.e., numbers before letters, and uppercase letters before lowercase ones).
  </para>

  <para>
   A record can have several formats:
<synopsis>
local               <replaceable>database</replaceable>  <replaceable>user</replaceable>  <replaceable>auth-method</replaceable> <optional><replaceable>auth-options</replaceable></optional>
host                <replaceable>database</replaceable>  <replaceable>user</replaceable>  <replaceable>address</replaceable>     <replaceable>auth-method</replaceable>  <optional><replaceable>auth-options</replaceable></optional>
hostssl