doc: Fix whitespace
Author: Julien Rouhaud <rjuju123@gmail.com>
This commit is contained in:
parent
45f8eaa8e3
commit
122fa9f942
|
@ -671,7 +671,7 @@ hostnogssenc <replaceable>database</replaceable> <replaceable>user</replaceable
|
|||
non-null <structfield>error</structfield> fields indicate problems in the
|
||||
corresponding lines of the file.
|
||||
</para>
|
||||
|
||||
|
||||
<tip>
|
||||
<para>
|
||||
To connect to a particular database, a user must not only pass the
|
||||
|
@ -747,9 +747,9 @@ host all all .example.com scram-sha-256
|
|||
# reject all connections from 192.168.54.1 (since that entry will be
|
||||
# matched first), but allow GSSAPI-encrypted connections from anywhere else
|
||||
# on the Internet. The zero mask causes no bits of the host IP address to
|
||||
# be considered, so it matches any host. Unencrypted GSSAPI connections
|
||||
# be considered, so it matches any host. Unencrypted GSSAPI connections
|
||||
# (which "fall through" to the third line since "hostgssenc" only matches
|
||||
# encrypted GSSAPI connections) are allowed, but only from 192.168.12.10.
|
||||
# encrypted GSSAPI connections) are allowed, but only from 192.168.12.10.
|
||||
#
|
||||
# TYPE DATABASE USER ADDRESS METHOD
|
||||
host all all 192.168.54.1/32 reject
|
||||
|
|
|
@ -953,7 +953,7 @@ include_dir 'conf.d'
|
|||
This parameter is supported only on systems that support
|
||||
<symbol>TCP_USER_TIMEOUT</symbol>; on other systems, it must be zero.
|
||||
In sessions connected via a Unix-domain socket, this parameter is
|
||||
ignored and always reads as zero.
|
||||
ignored and always reads as zero.
|
||||
</para>
|
||||
<note>
|
||||
<para>
|
||||
|
|
|
@ -312,7 +312,7 @@ current=testdb1 (should be testdb1)
|
|||
</para>
|
||||
|
||||
<para>
|
||||
The third option is to declare a sql identifier linked to
|
||||
The third option is to declare a sql identifier linked to
|
||||
the connection, for example:
|
||||
<programlisting>
|
||||
EXEC SQL AT <replaceable>connection-name</replaceable> DECLARE <replaceable>statement-name</replaceable> STATEMENT;
|
||||
|
@ -558,7 +558,7 @@ EXEC SQL COMMIT;
|
|||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry>
|
||||
<term><literal>EXEC SQL SET AUTOCOMMIT TO ON</literal></term>
|
||||
<listitem>
|
||||
|
@ -6843,7 +6843,7 @@ EXEC SQL [ AT <replaceable class="parameter">connection_name</replaceable> ] DEC
|
|||
A database connection name established by the <command>CONNECT</command> command.
|
||||
</para>
|
||||
<para>
|
||||
If AT clause is omitted, an SQL statement identifier is associated with the DEFAULT connection.
|
||||
If AT clause is omitted, an SQL statement identifier is associated with the DEFAULT connection.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
@ -6862,10 +6862,10 @@ EXEC SQL [ AT <replaceable class="parameter">connection_name</replaceable> ] DEC
|
|||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Notes</title>
|
||||
<title>Notes</title>
|
||||
<para>
|
||||
AT clause can be used at other dynamic SQL statements. The following table
|
||||
gives the connected database when AT clause is used at DECLARE STATEMENT
|
||||
gives the connected database when AT clause is used at DECLARE STATEMENT
|
||||
and other dynamic statements.
|
||||
</para>
|
||||
<table tocentry="1" id="ecpg-declare-statement-table">
|
||||
|
|
|
@ -17397,7 +17397,7 @@ SET search_path TO <replaceable>schema</replaceable> <optional>, <replaceable>sc
|
|||
because it needs access to the predicate lock manager's shared
|
||||
state for a short time.
|
||||
</para>
|
||||
|
||||
|
||||
<indexterm>
|
||||
<primary>version</primary>
|
||||
</indexterm>
|
||||
|
@ -21225,7 +21225,7 @@ postgres=# SELECT * FROM pg_walfile_name_offset(pg_stop_backup());
|
|||
<row><entry>Name</entry> <entry>Return Type</entry> <entry>Description</entry></row>
|
||||
</thead>
|
||||
|
||||
<tbody>
|
||||
<tbody>
|
||||
<row>
|
||||
<entry>
|
||||
<indexterm><primary>pg_partition_tree</primary></indexterm>
|
||||
|
|
|
@ -1518,7 +1518,7 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)'
|
|||
processing would request a file from the WAL archive, reporting failure
|
||||
if the file was unavailable. For standby processing it is normal for
|
||||
the next WAL file to be unavailable, so the standby must wait for
|
||||
it to appear. For files ending in
|
||||
it to appear. For files ending in
|
||||
<literal>.history</literal> there is no need to wait, and a non-zero return
|
||||
code must be returned. A waiting <varname>restore_command</varname> can be
|
||||
written as a custom script that loops after polling for the existence of
|
||||
|
|
|
@ -625,7 +625,7 @@ SELECT jdoc->'guid', jdoc->'name' FROM api WHERE jdoc @> '{"tags": ["qu
|
|||
</sect2>
|
||||
|
||||
<sect2 id="datatype-jsonpath">
|
||||
<title>jsonpath Type</title>
|
||||
<title>jsonpath Type</title>
|
||||
|
||||
<indexterm zone="datatype-jsonpath">
|
||||
<primary>jsonpath</primary>
|
||||
|
|
|
@ -3622,7 +3622,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
|
|||
with write locks that can potentially see the table to finish.
|
||||
This phase is skipped when not in concurrent mode.
|
||||
Columns <structname>lockers_total</structname>, <structname>lockers_done</structname>
|
||||
and <structname>current_locker_pid</structname> contain the progress
|
||||
and <structname>current_locker_pid</structname> contain the progress
|
||||
information for this phase.
|
||||
</entry>
|
||||
</row>
|
||||
|
@ -3644,7 +3644,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
|
|||
with write locks that can potentially write into the table to finish.
|
||||
This phase is skipped when not in concurrent mode.
|
||||
Columns <structname>lockers_total</structname>, <structname>lockers_done</structname>
|
||||
and <structname>current_locker_pid</structname> contain the progress
|
||||
and <structname>current_locker_pid</structname> contain the progress
|
||||
information for this phase.
|
||||
</entry>
|
||||
</row>
|
||||
|
@ -3682,7 +3682,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
|
|||
that can potentially see the table to release their snapshots. This
|
||||
phase is skipped when not in concurrent mode.
|
||||
Columns <structname>lockers_total</structname>, <structname>lockers_done</structname>
|
||||
and <structname>current_locker_pid</structname> contain the progress
|
||||
and <structname>current_locker_pid</structname> contain the progress
|
||||
information for this phase.
|
||||
</entry>
|
||||
</row>
|
||||
|
@ -3693,7 +3693,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
|
|||
with read locks on the table to finish, before marking the old index dead.
|
||||
This phase is skipped when not in concurrent mode.
|
||||
Columns <structname>lockers_total</structname>, <structname>lockers_done</structname>
|
||||
and <structname>current_locker_pid</structname> contain the progress
|
||||
and <structname>current_locker_pid</structname> contain the progress
|
||||
information for this phase.
|
||||
</entry>
|
||||
</row>
|
||||
|
@ -3704,7 +3704,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
|
|||
with read locks on the table to finish, before dropping the old index.
|
||||
This phase is skipped when not in concurrent mode.
|
||||
Columns <structname>lockers_total</structname>, <structname>lockers_done</structname>
|
||||
and <structname>current_locker_pid</structname> contain the progress
|
||||
and <structname>current_locker_pid</structname> contain the progress
|
||||
information for this phase.
|
||||
</entry>
|
||||
</row>
|
||||
|
@ -3725,8 +3725,8 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
|
|||
that will be reported and provide information about how to interpret it.
|
||||
Progress for <command>VACUUM FULL</command> commands is reported via
|
||||
<structname>pg_stat_progress_cluster</structname>
|
||||
because both <command>VACUUM FULL</command> and <command>CLUSTER</command>
|
||||
rewrite the table, while regular <command>VACUUM</command> only modifies it
|
||||
because both <command>VACUUM FULL</command> and <command>CLUSTER</command>
|
||||
rewrite the table, while regular <command>VACUUM</command> only modifies it
|
||||
in place. See <xref linkend='cluster-progress-reporting'/>.
|
||||
</para>
|
||||
|
||||
|
@ -3912,7 +3912,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
|
|||
<para>
|
||||
Whenever <command>CLUSTER</command> or <command>VACUUM FULL</command> is
|
||||
running, the <structname>pg_stat_progress_cluster</structname> view will
|
||||
contain a row for each backend that is currently running either command.
|
||||
contain a row for each backend that is currently running either command.
|
||||
The tables below describe the information that will be reported and
|
||||
provide information about how to interpret it.
|
||||
</para>
|
||||
|
@ -4054,7 +4054,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
|
|||
<row>
|
||||
<entry><literal>sorting tuples</literal></entry>
|
||||
<entry>
|
||||
<command>CLUSTER</command> is currently sorting tuples.
|
||||
<command>CLUSTER</command> is currently sorting tuples.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
|
@ -4072,7 +4072,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
|
|||
<row>
|
||||
<entry><literal>performing final cleanup</literal></entry>
|
||||
<entry>
|
||||
The command is performing final cleanup. When this phase is
|
||||
The command is performing final cleanup. When this phase is
|
||||
completed, <command>CLUSTER</command>
|
||||
or <command>VACUUM FULL</command> will end.
|
||||
</entry>
|
||||
|
|
|
@ -102,7 +102,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
|
|||
order-preserving merge. In contrast, <literal>Gather</literal> reads tuples
|
||||
from the workers in whatever order is convenient, destroying any sort
|
||||
order that may have existed.
|
||||
</para>
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="when-can-parallel-query-be-used">
|
||||
|
@ -347,7 +347,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
|
|||
workers in order to produce the final result. This is reflected in the
|
||||
plan as a <literal>Finalize Aggregate</literal> node.
|
||||
</para>
|
||||
|
||||
|
||||
<para>
|
||||
Because the <literal>Finalize Aggregate</literal> node runs on the leader
|
||||
process, queries which produce a relatively large number of groups in
|
||||
|
|
|
@ -544,7 +544,7 @@
|
|||
|
||||
<para>
|
||||
<filename>postgres_fdw</filename> likewise establishes remote session settings
|
||||
for various parameters:
|
||||
for various parameters:
|
||||
<itemizedlist spacing="compact">
|
||||
<listitem>
|
||||
<para>
|
||||
|
|
|
@ -1586,7 +1586,7 @@ PostgreSQL is <literal>tls-server-end-point</literal>.
|
|||
user-supplied password in the transmitted password hash. While this
|
||||
prevents the password hash from being successfully retransmitted in
|
||||
a later session, it does not prevent a fake server between the real
|
||||
server and client from passing through the server's random value
|
||||
server and client from passing through the server's random value
|
||||
and successfully authenticating.
|
||||
</para>
|
||||
|
||||
|
|
|
@ -327,7 +327,7 @@ PostgreSQL documentation
|
|||
</para>
|
||||
<para>
|
||||
When tar format mode is used, the write-ahead log files will be
|
||||
written to a separate file named <filename>pg_wal.tar</filename>
|
||||
written to a separate file named <filename>pg_wal.tar</filename>
|
||||
(if the server is a version earlier than 10, the file will be named
|
||||
<filename>pg_xlog.tar</filename>).
|
||||
</para>
|
||||
|
|
|
@ -260,7 +260,7 @@ GRANT EXECUTE ON function pg_catalog.pg_ls_dir(text, boolean, boolean) TO rewind
|
|||
GRANT EXECUTE ON function pg_catalog.pg_stat_file(text, boolean) TO rewind_user;
|
||||
GRANT EXECUTE ON function pg_catalog.pg_read_binary_file(text) TO rewind_user;
|
||||
GRANT EXECUTE ON function pg_catalog.pg_read_binary_file(text, bigint, bigint, boolean) TO rewind_user;
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
|
|
@ -796,7 +796,7 @@ psql --username=postgres --file=script.sql postgres
|
|||
In <productname>PostgreSQL</productname> 12 and later small tables by
|
||||
default don't have a free space map, as a space optimization. If you are
|
||||
upgrading a pre-12 cluster, the free space maps of small tables will
|
||||
likewise not be transferred to the new cluster.
|
||||
likewise not be transferred to the new cluster.
|
||||
</para>
|
||||
|
||||
</refsect1>
|
||||
|
|
|
@ -643,7 +643,7 @@ psql: could not connect to server: No such file or directory
|
|||
amount of anonymous <function>mmap</function> shared memory.
|
||||
Alternatively, a single large System V shared memory region can be used
|
||||
(see <xref linkend="guc-shared-memory-type"/>).
|
||||
|
||||
|
||||
In addition a significant number of semaphores, which can be either
|
||||
System V or POSIX style, are created at server startup. Currently,
|
||||
POSIX semaphores are used on Linux and FreeBSD systems while other
|
||||
|
|
|
@ -160,7 +160,7 @@
|
|||
</entry>
|
||||
<entry>
|
||||
<literal><-></literal>
|
||||
</entry>
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>text_ops</literal></entry>
|
||||
|
|
Loading…
Reference in New Issue