Skip to content

P
Postgres FD Implementation
Commit 03c25dd9 authored by Bruce Momjian's avatar Bruce Momjian
Browse files
Options

Mark all GUC variables with <varname> markup, rather than <literal>.

parent 2b6e2dee
Show whitespace changes
Inline Side-by-side
Showing with 60 additions and 60 deletions
doc/src/sgml/datetime.sgml
View file @ 03c25dd9
......@@ -360,10 +360,10 @@
</para>
<para>
<literal>timezone_abbreviations</> can be set to any file name
<varname>timezone_abbreviations</> can be set to any file name
found in <filename>.../share/timezonesets/</>, if the file's name
is entirely alphabetic. (The prohibition against non-alphabetic
characters in <literal>timezone_abbreviations</> prevents reading
characters in <varname>timezone_abbreviations</> prevents reading
files outside the intended directory, as well as reading editor
backup files and other extraneous files.)
</para>
......@@ -420,7 +420,7 @@
according to the <literal>zoneinfo</> timezone database. The zone name
definitions found in these files can be copied and pasted into a custom
configuration file as needed. Note that these files cannot be directly
referenced as <literal>timezone_abbreviations</> settings, because of
referenced as <varname>timezone_abbreviations</> settings, because of
the dot embedded in their names.
</para>
......
doc/src/sgml/libpq.sgml
View file @ 03c25dd9
......@@ -1418,46 +1418,46 @@ const char *PQparameterStatus(const PGconn *conn, const char *paramName);
<para>
Parameters reported as of the current release include
<literal>server_version</>,
<literal>server_encoding</>,
<literal>client_encoding</>,
<literal>application_name</>,
<literal>is_superuser</>,
<literal>session_authorization</>,
<literal>DateStyle</>,
<literal>IntervalStyle</>,
<literal>TimeZone</>,
<literal>integer_datetimes</>, and
<literal>standard_conforming_strings</>.
(<literal>server_encoding</>, <literal>TimeZone</>, and
<literal>integer_datetimes</> were not reported by releases before 8.0;
<literal>standard_conforming_strings</> was not reported by releases
<varname>server_version</>,
<varname>server_encoding</>,
<varname>client_encoding</>,
<varname>application_name</>,
<varname>is_superuser</>,
<varname>session_authorization</>,
<varname>DateStyle</>,
<varname>IntervalStyle</>,
<varname>TimeZone</>,
<varname>integer_datetimes</>, and
<varname>standard_conforming_strings</>.
(<varname>server_encoding</>, <varname>TimeZone</>, and
<varname>integer_datetimes</> were not reported by releases before 8.0;
<varname>standard_conforming_strings</> was not reported by releases
before 8.1;
<literal>IntervalStyle</> was not reported by releases before 8.4;
<literal>application_name</> was not reported by releases before 9.0.)
<varname>IntervalStyle</> was not reported by releases before 8.4;
<varname>application_name</> was not reported by releases before 9.0.)
Note that
<literal>server_version</>,
<literal>server_encoding</> and
<literal>integer_datetimes</>
<varname>server_version</>,
<varname>server_encoding</> and
<varname>integer_datetimes</>
cannot change after startup.
</para>
<para>
Pre-3.0-protocol servers do not report parameter settings, but
<application>libpq</> includes logic to obtain values for
<literal>server_version</> and <literal>client_encoding</> anyway.
<varname>server_version</> and <varname>client_encoding</> anyway.
Applications are encouraged to use <function>PQparameterStatus</>
rather than <foreignphrase>ad hoc</> code to determine these values.
(Beware however that on a pre-3.0 connection, changing
<literal>client_encoding</> via <command>SET</> after connection
<varname>client_encoding</> via <command>SET</> after connection
startup will not be reflected by <function>PQparameterStatus</>.)
For <literal>server_version</>, see also
For <varname>server_version</>, see also
<function>PQserverVersion</>, which returns the information in a
numeric form that is much easier to compare against.
</para>
<para>
If no value for <literal>standard_conforming_strings</> is reported,
If no value for <varname>standard_conforming_strings</> is reported,
applications can assume it is <literal>off</>, that is, backslashes
are treated as escapes in string literals. Also, the presence of
this parameter can be taken as an indication that the escape string
......
doc/src/sgml/maintenance.sgml
View file @ 03c25dd9
......@@ -670,13 +670,13 @@ analyze threshold = analyze base threshold + analyze scale factor * number of tu
autovacuum will only touch the table if it must do so
to prevent transaction ID wraparound.
Another two parameters,
<literal>autovacuum_vacuum_cost_delay</literal> and
<literal>autovacuum_vacuum_cost_limit</literal>, are used to set
<varname>autovacuum_vacuum_cost_delay</> and
<varname>autovacuum_vacuum_cost_limit</>, are used to set
table-specific values for the cost-based vacuum delay feature
(see <xref linkend="runtime-config-resource-vacuum-cost">).
<literal>autovacuum_freeze_min_age</literal>,
<literal>autovacuum_freeze_max_age</literal> and
<literal>autovacuum_freeze_table_age</literal> are used to set
<varname>autovacuum_freeze_min_age</>,
<varname>autovacuum_freeze_max_age</> and
<varname>autovacuum_freeze_table_age</> are used to set
values for <xref linkend="guc-vacuum-freeze-min-age">,
<xref linkend="guc-autovacuum-freeze-max-age"> and
<xref linkend="guc-vacuum-freeze-table-age"> respectively.
......@@ -764,7 +764,7 @@ analyze threshold = analyze base threshold + analyze scale factor * number of tu
A better approach is to send the server's
<systemitem>stderr</> output to some type of log rotation program.
There is a built-in log rotation facility, which you can use by
setting the configuration parameter <literal>logging_collector</> to
setting the configuration parameter <varname>logging_collector</> to
<literal>true</> in <filename>postgresql.conf</>. The control
parameters for this program are described in <xref
linkend="runtime-config-logging-where">. You can also use this approach
......@@ -794,7 +794,7 @@ pg_ctl start | rotatelogs /var/log/pgsql_log 86400
Another production-grade approach to managing log output is to
send it to <application>syslog</> and let
<application>syslog</> deal with file rotation. To do this, set the
configuration parameter <literal>log_destination</> to <literal>syslog</>
configuration parameter <varname>log_destination</> to <literal>syslog</>
(to log to <application>syslog</> only) in
<filename>postgresql.conf</>. Then you can send a <literal>SIGHUP</literal>
signal to the <application>syslog</> daemon whenever you want to force it
......
doc/src/sgml/pgarchivecleanup.sgml
View file @ 03c25dd9
......@@ -111,7 +111,7 @@ pg_archivecleanup: removing file "archive/00000001000000370000000E"
archive_cleanup_command = 'pg_archivecleanup -d /mnt/standby/archive %r 2>>cleanup.log'
</programlisting>
where the archive directory is physically located on the standby server,
so that the <literal>archive_command</> is accessing it across NFS,
so that the <varname>archive_command</> is accessing it across NFS,
but the files are local to the standby.
This will:
</para>
......
doc/src/sgml/pgstandby.sgml
View file @ 03c25dd9
......@@ -15,7 +15,7 @@
<para>
<application>pg_standby</> is designed to be a waiting
<literal>restore_command</literal>, which is needed to turn a standard
<varname>restore_command</>, which is needed to turn a standard
archive recovery into a warm standby operation. Other
configuration is required as well, all of which is described in the main
server manual (see <xref linkend="warm-standby">).
......@@ -61,7 +61,7 @@ restore_command = 'pg_standby <replaceable>archiveDir</> %f %p %r'
<synopsis>
pg_standby <optional> <replaceable>option</> ... </optional> <replaceable>archivelocation</> <replaceable>nextwalfile</> <replaceable>xlogfilepath</> <optional> <replaceable>restartwalfile</> </optional>
</synopsis>
When used within <literal>restore_command</literal>, the <literal>%f</> and
When used within <varname>restore_command</>, the <literal>%f</> and
<literal>%p</> macros should be specified for <replaceable>nextwalfile</>
and <replaceable>xlogfilepath</> respectively, to provide the actual file
and path required for the restore.
......@@ -241,7 +241,7 @@ restore_command = 'pg_standby -d -s 2 -t /tmp/pgsql.trigger.5442 .../archive %f
recovery_end_command = 'rm -f /tmp/pgsql.trigger.5442'
</programlisting>
where the archive directory is physically located on the standby server,
so that the <literal>archive_command</> is accessing it across NFS,
so that the <varname>archive_command</> is accessing it across NFS,
but the files are local to the standby (enabling use of <literal>ln</>).
This will:
<itemizedlist>
......@@ -285,8 +285,8 @@ restore_command = 'pg_standby -d -s 5 -t C:\pgsql.trigger.5442 ...\archive %f %p
recovery_end_command = 'del C:\pgsql.trigger.5442'
</programlisting>
Note that backslashes need to be doubled in the
<literal>archive_command</>, but <emphasis>not</emphasis> in the
<literal>restore_command</> or <literal>recovery_end_command</>.
<varname>archive_command</>, but <emphasis>not</emphasis> in the
<varname>restore_command</> or <varname>recovery_end_command</>.
This will:
<itemizedlist>
<listitem>
......@@ -357,7 +357,7 @@ recovery_end_command = 'del C:\pgsql.trigger.5442'
</para>
<para>
<productname>PostgreSQL</> 8.4 provides the
<literal>recovery_end_command</literal> option. Without this option
<varname>recovery_end_command</> option. Without this option
a leftover trigger file can be hazardous.
</para>
</sect2>
......
doc/src/sgml/protocol.sgml
View file @ 03c25dd9
......@@ -1092,27 +1092,27 @@
<para>
At present there is a hard-wired set of parameters for which
ParameterStatus will be generated: they are
<literal>server_version</>,
<literal>server_encoding</>,
<literal>client_encoding</>,
<literal>application_name</>,
<literal>is_superuser</>,
<literal>session_authorization</>,
<literal>DateStyle</>,
<literal>IntervalStyle</>,
<literal>TimeZone</>,
<literal>integer_datetimes</>, and
<literal>standard_conforming_strings</>.
(<literal>server_encoding</>, <literal>TimeZone</>, and
<literal>integer_datetimes</> were not reported by releases before 8.0;
<literal>standard_conforming_strings</> was not reported by releases
<varname>server_version</>,
<varname>server_encoding</>,
<varname>client_encoding</>,
<varname>application_name</>,
<varname>is_superuser</>,
<varname>session_authorization</>,
<varname>DateStyle</>,
<varname>IntervalStyle</>,
<varname>TimeZone</>,
<varname>integer_datetimes</>, and
<varname>standard_conforming_strings</>.
(<varname>server_encoding</>, <varname>TimeZone</>, and
<varname>integer_datetimes</> were not reported by releases before 8.0;
<varname>standard_conforming_strings</> was not reported by releases
before 8.1;
<literal>IntervalStyle</> was not reported by releases before 8.4;
<literal>application_name</> was not reported by releases before 9.0.)
<varname>IntervalStyle</> was not reported by releases before 8.4;
<varname>application_name</> was not reported by releases before 9.0.)
Note that
<literal>server_version</>,
<literal>server_encoding</> and
<literal>integer_datetimes</>
<varname>server_version</>,
<varname>server_encoding</> and
<varname>integer_datetimes</>
are pseudo-parameters that cannot change after startup.
This set might change in the future, or even become configurable.
Accordingly, a frontend should simply ignore ParameterStatus for
......
doc/src/sgml/ref/pg_dump.sgml
View file @ 03c25dd9
......@@ -864,7 +864,7 @@ PostgreSQL documentation
<para>
The database activity of <application>pg_dump</application> is
normally collected by the statistics collector. If this is
undesirable, you can set parameter <literal>track_counts</literal>
undesirable, you can set parameter <varname>track_counts</>
to false via <envar>PGOPTIONS</envar> or the <literal>ALTER
USER</literal> command.
</para>
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment