- <literal>timezone_abbreviations can be set to any file name
+ <varname>timezone_abbreviations can be set to any file name
found in .../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.)
according to the 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.
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, >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, >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.
Pre-3.0-protocol servers do not report parameter settings, but
libpq includes logic to obtain values for
- <literal>server_version and >client_encoding anyway.
+ <varname>server_version and >client_encoding anyway.
Applications are encouraged to use PQparameterStatus
rather than ad hoc code to determine these values.
(Beware however that on a pre-3.0 connection, changing
- <literal>client_encoding via SET after connection
+ <varname>client_encoding via SET after connection
startup will not be reflected by PQparameterStatus.)
- For <literal>server_version, see also
+ For <varname>server_version, see also
PQserverVersion, which returns the information in a
numeric form that is much easier to compare against.
- 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 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
autovacuum will only touch the table if it must do so
to prevent transaction ID wraparound.
Another two parameters,
- <literal>autovacuum_vacuum_cost_delay> and
- <literal>autovacuum_vacuum_cost_limit>, 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 ).
- <literal>autovacuum_freeze_min_age>,
- <literal>autovacuum_freeze_max_age> and
- <literal>autovacuum_freeze_table_age> 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 ,
and
respectively.
A better approach is to send the server's
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
true in postgresql.conf. The control
parameters for this program are described in
linkend="runtime-config-logging-where">. You can also use this approach
Another production-grade approach to managing log output is to
send it to
syslog and let syslog deal with file rotation. To do this, set the
- configuration parameter <literal>log_destination to syslog
+ configuration parameter <varname>log_destination to syslog
(to log to
syslog only) in postgresql.conf. Then you can send a SIGHUP
signal to the
syslog daemon whenever you want to force it
archive_cleanup_command = 'pg_archivecleanup -d /mnt/standby/archive %r 2>>cleanup.log'
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:
pg_standby is designed to be a waiting
- <literal>restore_command>, 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 ).
pg_standby option ... archivelocation nextwalfile xlogfilepath restartwalfile
- When used within <literal>restore_command>, the %f and
+ When used within <varname>restore_command>, the %f and
%p macros should be specified for nextwalfile
and xlogfilepath respectively, to provide the actual file
and path required for the restore.
recovery_end_command = 'rm -f /tmp/pgsql.trigger.5442'
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 ln).
This will:
recovery_end_command = 'del C:\pgsql.trigger.5442'
Note that backslashes need to be doubled in the
- <literal>archive_command, but not in the
- <literal>restore_command or >recovery_end_command.
+ <varname>archive_command, but not in the
+ <varname>restore_command or >recovery_end_command.
This will:
PostgreSQL 8.4 provides the
- <literal>recovery_end_command> option. Without this option
+ <varname>recovery_end_command> option. Without this option
a leftover trigger file can be hazardous.
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, >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, >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
The database activity of
pg_dump is
normally collected by the statistics collector. If this is
- undesirable, you can set parameter <literal>track_counts>
+ undesirable, you can set parameter <varname>track_counts>
to false via PGOPTIONS or the ALTER
USER command.
projects / postgresql.git / commitdiff