# config/docbook.m4
-# PGAC_PROG_NSGMLS
-# ----------------
-AC_DEFUN([PGAC_PROG_NSGMLS],
-[PGAC_PATH_PROGS(NSGMLS, [onsgmls nsgmls])])
+# PGAC_PATH_XMLLINT
+# -----------------
+AC_DEFUN([PGAC_PATH_XMLLINT],
+[PGAC_PATH_PROGS(XMLLINT, xmllint)])
# PGAC_CHECK_DOCBOOK(VERSION)
# ---------------------------
AC_DEFUN([PGAC_CHECK_DOCBOOK],
-[AC_REQUIRE([PGAC_PROG_NSGMLS])
-AC_CACHE_CHECK([for DocBook V$1], [pgac_cv_check_docbook],
-[cat >conftest.sgml <<EOF
-<!doctype book PUBLIC "-//OASIS//DTD DocBook V$1//EN">
+[AC_REQUIRE([PGAC_PATH_XMLLINT])
+AC_CACHE_CHECK([for DocBook XML V$1], [pgac_cv_check_docbook],
+[cat >conftest.xml <<EOF
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V$1//EN" "http://www.oasis-open.org/docbook/xml/$1/docbookx.dtd">
<book>
<title>test</title>
<chapter>
pgac_cv_check_docbook=no
-if test -n "$NSGMLS"; then
- $NSGMLS -s conftest.sgml 1>&AS_MESSAGE_LOG_FD 2>&1
+if test -n "$XMLLINT"; then
+ $XMLLINT --noout --valid conftest.xml 1>&AS_MESSAGE_LOG_FD 2>&1
if test $? -eq 0; then
pgac_cv_check_docbook=yes
fi
fi
-rm -f conftest.sgml])
+rm -f conftest.xml])
have_docbook=$pgac_cv_check_docbook
AC_SUBST([have_docbook])
PG_VERSION_NUM
PROVE
FOP
-OSX
XSLTPROC
-XMLLINT
DBTOEPUB
have_docbook
-NSGMLS
+XMLLINT
TCL_SHLIB_LD_LIBS
TCL_SHARED_BUILD
TCL_LIB_SPEC
#
# Check for DocBook and tools
#
-if test -z "$NSGMLS"; then
- for ac_prog in onsgmls nsgmls
+if test -z "$XMLLINT"; then
+ for ac_prog in xmllint
do
# Extract the first word of "$ac_prog", so it can be a program name with args.
set dummy $ac_prog; ac_word=$2
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
$as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_path_NSGMLS+:} false; then :
+if ${ac_cv_path_XMLLINT+:} false; then :
$as_echo_n "(cached) " >&6
else
- case $NSGMLS in
+ case $XMLLINT in
[\\/]* | ?:[\\/]*)
- ac_cv_path_NSGMLS="$NSGMLS" # Let the user override the test with a path.
+ ac_cv_path_XMLLINT="$XMLLINT" # Let the user override the test with a path.
;;
*)
as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
test -z "$as_dir" && as_dir=.
for ac_exec_ext in '' $ac_executable_extensions; do
if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
- ac_cv_path_NSGMLS="$as_dir/$ac_word$ac_exec_ext"
+ ac_cv_path_XMLLINT="$as_dir/$ac_word$ac_exec_ext"
$as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
break 2
fi
;;
esac
fi
-NSGMLS=$ac_cv_path_NSGMLS
-if test -n "$NSGMLS"; then
- { $as_echo "$as_me:${as_lineno-$LINENO}: result: $NSGMLS" >&5
-$as_echo "$NSGMLS" >&6; }
+XMLLINT=$ac_cv_path_XMLLINT
+if test -n "$XMLLINT"; then
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: $XMLLINT" >&5
+$as_echo "$XMLLINT" >&6; }
else
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
$as_echo "no" >&6; }
fi
- test -n "$NSGMLS" && break
+ test -n "$XMLLINT" && break
done
else
- # Report the value of NSGMLS in configure's output in all cases.
- { $as_echo "$as_me:${as_lineno-$LINENO}: checking for NSGMLS" >&5
-$as_echo_n "checking for NSGMLS... " >&6; }
- { $as_echo "$as_me:${as_lineno-$LINENO}: result: $NSGMLS" >&5
-$as_echo "$NSGMLS" >&6; }
+ # Report the value of XMLLINT in configure's output in all cases.
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking for XMLLINT" >&5
+$as_echo_n "checking for XMLLINT... " >&6; }
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: $XMLLINT" >&5
+$as_echo "$XMLLINT" >&6; }
fi
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for DocBook V4.2" >&5
-$as_echo_n "checking for DocBook V4.2... " >&6; }
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for DocBook XML V4.2" >&5
+$as_echo_n "checking for DocBook XML V4.2... " >&6; }
if ${pgac_cv_check_docbook+:} false; then :
$as_echo_n "(cached) " >&6
else
- cat >conftest.sgml <<EOF
-<!doctype book PUBLIC "-//OASIS//DTD DocBook V4.2//EN">
+ cat >conftest.xml <<EOF
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<book>
<title>test</title>
<chapter>
pgac_cv_check_docbook=no
-if test -n "$NSGMLS"; then
- $NSGMLS -s conftest.sgml 1>&5 2>&1
+if test -n "$XMLLINT"; then
+ $XMLLINT --noout --valid conftest.xml 1>&5 2>&1
if test $? -eq 0; then
pgac_cv_check_docbook=yes
fi
fi
-rm -f conftest.sgml
+rm -f conftest.xml
fi
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $pgac_cv_check_docbook" >&5
$as_echo "$pgac_cv_check_docbook" >&6; }
$as_echo "$DBTOEPUB" >&6; }
fi
-if test -z "$XMLLINT"; then
- for ac_prog in xmllint
-do
- # Extract the first word of "$ac_prog", so it can be a program name with args.
-set dummy $ac_prog; ac_word=$2
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
-$as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_path_XMLLINT+:} false; then :
- $as_echo_n "(cached) " >&6
-else
- case $XMLLINT in
- [\\/]* | ?:[\\/]*)
- ac_cv_path_XMLLINT="$XMLLINT" # Let the user override the test with a path.
- ;;
- *)
- as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
-for as_dir in $PATH
-do
- IFS=$as_save_IFS
- test -z "$as_dir" && as_dir=.
- for ac_exec_ext in '' $ac_executable_extensions; do
- if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
- ac_cv_path_XMLLINT="$as_dir/$ac_word$ac_exec_ext"
- $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
- break 2
- fi
-done
- done
-IFS=$as_save_IFS
-
- ;;
-esac
-fi
-XMLLINT=$ac_cv_path_XMLLINT
-if test -n "$XMLLINT"; then
- { $as_echo "$as_me:${as_lineno-$LINENO}: result: $XMLLINT" >&5
-$as_echo "$XMLLINT" >&6; }
-else
- { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
-$as_echo "no" >&6; }
-fi
-
-
- test -n "$XMLLINT" && break
-done
-
-else
- # Report the value of XMLLINT in configure's output in all cases.
- { $as_echo "$as_me:${as_lineno-$LINENO}: checking for XMLLINT" >&5
-$as_echo_n "checking for XMLLINT... " >&6; }
- { $as_echo "$as_me:${as_lineno-$LINENO}: result: $XMLLINT" >&5
-$as_echo "$XMLLINT" >&6; }
-fi
-
if test -z "$XSLTPROC"; then
for ac_prog in xsltproc
do
$as_echo "$XSLTPROC" >&6; }
fi
-if test -z "$OSX"; then
- for ac_prog in osx sgml2xml sx
-do
- # Extract the first word of "$ac_prog", so it can be a program name with args.
-set dummy $ac_prog; ac_word=$2
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
-$as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_path_OSX+:} false; then :
- $as_echo_n "(cached) " >&6
-else
- case $OSX in
- [\\/]* | ?:[\\/]*)
- ac_cv_path_OSX="$OSX" # Let the user override the test with a path.
- ;;
- *)
- as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
-for as_dir in $PATH
-do
- IFS=$as_save_IFS
- test -z "$as_dir" && as_dir=.
- for ac_exec_ext in '' $ac_executable_extensions; do
- if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
- ac_cv_path_OSX="$as_dir/$ac_word$ac_exec_ext"
- $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
- break 2
- fi
-done
- done
-IFS=$as_save_IFS
-
- ;;
-esac
-fi
-OSX=$ac_cv_path_OSX
-if test -n "$OSX"; then
- { $as_echo "$as_me:${as_lineno-$LINENO}: result: $OSX" >&5
-$as_echo "$OSX" >&6; }
-else
- { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
-$as_echo "no" >&6; }
-fi
-
-
- test -n "$OSX" && break
-done
-
-else
- # Report the value of OSX in configure's output in all cases.
- { $as_echo "$as_me:${as_lineno-$LINENO}: checking for OSX" >&5
-$as_echo_n "checking for OSX... " >&6; }
- { $as_echo "$as_me:${as_lineno-$LINENO}: result: $OSX" >&5
-$as_echo "$OSX" >&6; }
-fi
-
if test -z "$FOP"; then
for ac_prog in fop
do
#
# Check for DocBook and tools
#
-PGAC_PROG_NSGMLS
+PGAC_PATH_XMLLINT
PGAC_CHECK_DOCBOOK(4.2)
PGAC_PATH_PROGS(DBTOEPUB, dbtoepub)
-PGAC_PATH_PROGS(XMLLINT, xmllint)
PGAC_PATH_PROGS(XSLTPROC, xsltproc)
-PGAC_PATH_PROGS(OSX, [osx sgml2xml sx])
PGAC_PATH_PROGS(FOP, fop)
#
FOP = $(missing) fop
endif
-SGMLINCLUDE = -D . -D $(srcdir)
-
-ifndef NSGMLS
-NSGMLS = $(missing) nsgmls
-endif
-
-ifndef OSX
-OSX = $(missing) osx
-endif
+XMLINCLUDE = --path .
ifndef XMLLINT
XMLLINT = $(missing) xmllint
ALLSGML := $(wildcard $(srcdir)/*.sgml $(srcdir)/ref/*.sgml) $(GENERATED_SGML)
-# Enable some extra warnings
-# -wfully-tagged needed to throw a warning on missing tags
-# for older tool chains, 2007-08-31
-# -wnet catches XML-style empty-element tags like <xref linkend="abc"/>.
-override SPFLAGS += -wall -wno-unused-param -wfully-tagged -wnet
-# Additional warnings for XML compatibility. The conditional is meant
-# to detect whether we are using OpenSP rather than the ancient
-# original SP.
-override SPFLAGS += -wempty
-ifneq (,$(filter o%,$(notdir $(OSX))))
-override SPFLAGS += -wdata-delim -winstance-ignore-ms -winstance-include-ms -winstance-param-entity
-endif
-
##
## Man pages
man distprep-man: man-stamp
-man-stamp: stylesheet-man.xsl postgres.xml
- $(XMLLINT) --noout --valid postgres.xml
- $(XSLTPROC) $(XSLTPROCFLAGS) $(XSLTPROC_MAN_FLAGS) $^
+man-stamp: stylesheet-man.xsl postgres.sgml $(ALLSGML)
+ $(XMLLINT) $(XMLINCLUDE) --noout --valid $(word 2,$^)
+ $(XSLTPROC) $(XMLINCLUDE) $(XSLTPROCFLAGS) $(XSLTPROC_MAN_FLAGS) $(wordlist 1,2,$^)
touch $@
$(XMLLINT) --noout --valid $*.xml
$(XSLTPROC) $(XSLTPROCFLAGS) $(XSLTPROC_HTML_FLAGS) $^ >$@
-INSTALL.xml: standalone-profile.xsl standalone-install.xml postgres.xml
- $(XSLTPROC) $(XSLTPROCFLAGS) --xinclude $(wordlist 1,2,$^) >$@
-
-
-##
-## SGML->XML conversion
-##
-
-# For obscure reasons, GNU make 3.81 complains about circular dependencies
-# if we try to do "make all" in a VPATH build without the explicit
-# $(srcdir) on the postgres.sgml dependency in this rule. GNU make bug?
-postgres.xml: $(srcdir)/postgres.sgml $(ALLSGML)
- $(OSX) $(SPFLAGS) $(SGMLINCLUDE) -x lower $< >$@.tmp
- $(call mangle-xml,book)
-
-define mangle-xml
-$(PERL) -p -e 's/\[(aacute|acirc|aelig|agrave|amp|aring|atilde|auml|bull|copy|eacute|egrave|gt|iacute|lt|mdash|nbsp|ntilde|oacute|ocirc|oslash|ouml|pi|quot|scaron|uuml) *\]/\&\1;/gi;' \
- -e '$$_ .= qq{<!DOCTYPE $(1) PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">\n} if $$. == 1;' \
- <$@.tmp > $@
-rm $@.tmp
-endef
+INSTALL.xml: standalone-profile.xsl standalone-install.xml postgres.sgml $(ALLSGML)
+ $(XSLTPROC) $(XMLINCLUDE) $(XSLTPROCFLAGS) --xinclude $(wordlist 1,2,$^) >$@
##
html: html-stamp
-html-stamp: stylesheet.xsl postgres.xml
- $(XMLLINT) --noout --valid postgres.xml
- $(XSLTPROC) $(XSLTPROCFLAGS) $(XSLTPROC_HTML_FLAGS) $^
+html-stamp: stylesheet.xsl postgres.sgml $(ALLSGML)
+ $(XMLLINT) $(XMLINCLUDE) --noout --valid $(word 2,$^)
+ $(XSLTPROC) $(XMLINCLUDE) $(XSLTPROCFLAGS) $(XSLTPROC_HTML_FLAGS) $(wordlist 1,2,$^)
cp $(srcdir)/stylesheet.css html/
touch $@
-htmlhelp: stylesheet-hh.xsl postgres.xml
- $(XMLLINT) --noout --valid postgres.xml
- $(XSLTPROC) $(XSLTPROCFLAGS) $^
+htmlhelp: stylesheet-hh.xsl postgres.sgml $(ALLSGML)
+ $(XMLLINT) $(XMLINCLUDE) --noout --valid $(word 2,$^)
+ $(XSLTPROC) $(XMLINCLUDE) $(XSLTPROCFLAGS) $(wordlist 1,2,$^)
# single-page HTML
-postgres.html: stylesheet-html-nochunk.xsl postgres.xml
- $(XMLLINT) --noout --valid postgres.xml
- $(XSLTPROC) $(XSLTPROCFLAGS) $(XSLTPROC_HTML_FLAGS) -o $@ $^
+postgres.html: stylesheet-html-nochunk.xsl postgres.sgml $(ALLSGML)
+ $(XMLLINT) $(XMLINCLUDE) --noout --valid $(word 2,$^)
+ $(XSLTPROC) $(XMLINCLUDE) $(XSLTPROCFLAGS) $(XSLTPROC_HTML_FLAGS) -o $@ $(wordlist 1,2,$^)
# single-page text
postgres.txt: postgres.html
postgres.pdf:
$(error Invalid target; use postgres-A4.pdf or postgres-US.pdf as targets)
-%-A4.fo: stylesheet-fo.xsl %.xml
- $(XMLLINT) --noout --valid $*.xml
- $(XSLTPROC) $(XSLTPROCFLAGS) --stringparam paper.type A4 -o $@ $^
+%-A4.fo: stylesheet-fo.xsl %.sgml $(ALLSGML)
+ $(XMLLINT) $(XMLINCLUDE) --noout --valid $(word 2,$^)
+ $(XSLTPROC) $(XMLINCLUDE) $(XSLTPROCFLAGS) --stringparam paper.type A4 -o $@ $(wordlist 1,2,$^)
-%-US.fo: stylesheet-fo.xsl %.xml
- $(XMLLINT) --noout --valid $*.xml
- $(XSLTPROC) $(XSLTPROCFLAGS) --stringparam paper.type USletter -o $@ $^
+%-US.fo: stylesheet-fo.xsl %.sgml $(ALLSGML)
+ $(XMLLINT) $(XMLINCLUDE) --noout --valid $(word 2,$^)
+ $(XSLTPROC) $(XMLINCLUDE) $(XSLTPROCFLAGS) --stringparam paper.type USletter -o $@ $(wordlist 1,2,$^)
%.pdf: %.fo
$(FOP) -fo $< -pdf $@
##
epub: postgres.epub
-postgres.epub: postgres.xml
+postgres.epub: postgres.sgml $(ALLSGML)
$(XMLLINT) --noout --valid $<
$(DBTOEPUB) $<
DB2X_XSLTPROC = db2x_xsltproc
MAKEINFO = makeinfo
-%.texixml: %.xml
+%.texixml: %.sgml $(ALLSGML)
+ $(XMLLINT) --noout --valid $<
$(DB2X_XSLTPROC) -s texi -g output-file=$(basename $@) $< -o $@
%.texi: %.texixml
# Quick syntax check without style processing
check: postgres.sgml $(ALLSGML) check-tabs
- $(NSGMLS) $(SPFLAGS) $(SGMLINCLUDE) -s $<
+ $(XMLLINT) $(XMLINCLUDE) --noout --valid $<
##
# This allows removing some files from the distribution tarballs while
# keeping the dependencies satisfied.
-.SECONDARY: postgres.xml $(GENERATED_SGML)
+.SECONDARY: $(GENERATED_SGML)
.SECONDARY: INSTALL.html INSTALL.xml
.SECONDARY: postgres-A4.fo postgres-US.fo
rm -f *.fo *.pdf
# generated SGML files
rm -f $(GENERATED_SGML)
-# SGML->XML conversion
- rm -f postgres.xml *.tmp
# HTML Help
rm -f htmlhelp.hhp toc.hhc index.hhk
# EPUB
</para>
<para>
- The functions shown in <xref linkend="functions-adminpack-table"> provide
+ The functions shown in <xref linkend="functions-adminpack-table"/> provide
write access to files on the machine hosting the server. (See also the
- functions in <xref linkend="functions-admin-genfile-table">, which
+ functions in <xref linkend="functions-admin-genfile-table"/>, which
provide read-only access.)
Only files within the database cluster directory can be accessed, but
either a relative or absolute path is allowable.
</indexterm>
<para>
<function>pg_logdir_ls</function> returns the start timestamps and path
- names of all the log files in the <xref linkend="guc-log-directory">
- directory. The <xref linkend="guc-log-filename"> parameter must have its
+ names of all the log files in the <xref linkend="guc-log-directory"/>
+ directory. The <xref linkend="guc-log-filename"/> parameter must have its
default setting (<literal>postgresql-%Y-%m-%d_%H%M%S.log</literal>) to use this
function.
</para>
<para>
The functions shown
- in <xref linkend="functions-adminpack-deprecated-table"> are deprecated
+ in <xref linkend="functions-adminpack-deprecated-table"/> are deprecated
and should not be used in new applications; instead use those shown
- in <xref linkend="functions-admin-signal-table">
- and <xref linkend="functions-admin-genfile-table">. These functions are
+ in <xref linkend="functions-admin-signal-table"/>
+ and <xref linkend="functions-admin-genfile-table"/>. These functions are
provided in <filename>adminpack</filename> only for compatibility with old
versions of <application>pgAdmin</application>.
</para>
<para>
This chapter will on occasion refer to examples found in <xref
- linkend="tutorial-sql"> to change or improve them, so it will be
+ linkend="tutorial-sql"/> to change or improve them, so it will be
useful to have read that chapter. Some examples from
this chapter can also be found in
<filename>advanced.sql</filename> in the tutorial directory. This
file also contains some sample data to load, which is not
- repeated here. (Refer to <xref linkend="tutorial-sql-intro"> for
+ repeated here. (Refer to <xref linkend="tutorial-sql-intro"/> for
how to use the file.)
</para>
</sect1>
</indexterm>
<para>
- Refer back to the queries in <xref linkend="tutorial-join">.
+ Refer back to the queries in <xref linkend="tutorial-join"/>.
Suppose the combined listing of weather records and city location
is of particular interest to your application, but you do not want
to type the query each time you need it. You can create a
<para>
Recall the <classname>weather</classname> and
<classname>cities</classname> tables from <xref
- linkend="tutorial-sql">. Consider the following problem: You
+ linkend="tutorial-sql"/>. Consider the following problem: You
want to make sure that no one can insert rows in the
<classname>weather</classname> table that do not have a matching
entry in the <classname>cities</classname> table. This is called
<para>
The behavior of foreign keys can be finely tuned to your
application. We will not go beyond this simple example in this
- tutorial, but just refer you to <xref linkend="ddl">
+ tutorial, but just refer you to <xref linkend="ddl"/>
for more information. Making correct use of
foreign keys will definitely improve the quality of your database
applications, so you are strongly encouraged to learn about them.
<para>
There are options to define the window frame in other ways, but
this tutorial does not cover them. See
- <xref linkend="syntax-window-functions"> for details.
+ <xref linkend="syntax-window-functions"/> for details.
</para>
</footnote>
Here is an example using <function>sum</function>:
<para>
More details about window functions can be found in
- <xref linkend="syntax-window-functions">,
- <xref linkend="functions-window">,
- <xref linkend="queries-window">, and the
- <xref linkend="sql-select"> reference page.
+ <xref linkend="syntax-window-functions"/>,
+ <xref linkend="functions-window"/>,
+ <xref linkend="queries-window"/>, and the
+ <xref linkend="sql-select"/> reference page.
</para>
</sect1>
<para>
Although inheritance is frequently useful, it has not been integrated
with unique constraints or foreign keys, which limits its usefulness.
- See <xref linkend="ddl-inherit"> for more detail.
+ See <xref linkend="ddl-inherit"/> for more detail.
</para>
</note>
</sect1>
index scans themselves, which may be user-defined operator class
code. For example, B-Tree index verification relies on comparisons
made with one or more B-Tree support function 1 routines. See <xref
- linkend="xindex-support"> for details of operator class support
+ linkend="xindex-support"/> for details of operator class support
functions.
</para>
<para>
index that is ordered using an affected collation, simply because
<emphasis>indexed</emphasis> values might happen to have the same
absolute ordering regardless of the behavioral inconsistency. See
- <xref linkend="locale"> and <xref linkend="collation"> for
+ <xref linkend="locale"/> and <xref linkend="collation"/> for
further details about how <productname>PostgreSQL</productname> uses
operating system locales and collations.
</para>
logical inconsistency to be introduced. One obvious testing
strategy is to call <filename>amcheck</filename> functions continuously
when running the standard regression tests. See <xref
- linkend="regress-run"> for details on running the tests.
+ linkend="regress-run"/> for details on running the tests.
</para>
</listitem>
<listitem>
There is no general method of repairing problems that
<filename>amcheck</filename> detects. An explanation for the root cause of
an invariant violation should be sought. <xref
- linkend="pageinspect"> may play a useful role in diagnosing
+ linkend="pageinspect"/> may play a useful role in diagnosing
corruption that <filename>amcheck</filename> detects. A <command>REINDEX</command>
may not be effective in repairing corruption.
</para>
<title>Author</title>
<para>
This chapter originated as part of
- <xref linkend="sim98">, Stefan Simkovics'
+ <xref linkend="sim98"/>, Stefan Simkovics'
Master's Thesis prepared at Vienna University of Technology under the direction
of O.Univ.Prof.Dr. Georg Gottlob and Univ.Ass. Mag. Katrin Seyr.
</para>
<para>
The client process can be any program that understands the
<productname>PostgreSQL</productname> protocol described in
- <xref linkend="protocol">. Many clients are based on the
+ <xref linkend="protocol"/>. Many clients are based on the
C-language library <application>libpq</application>, but several independent
implementations of the protocol exist, such as the Java
<application>JDBC</application> driver.
<para>
The query rewriter is discussed in some detail in
- <xref linkend="rules">, so there is no need to cover it here.
+ <xref linkend="rules"/>, so there is no need to cover it here.
We will only point out that both the input and the output of the
rewriter are query trees, that is, there is no change in the
representation or level of semantic detail in the trees. Rewriting
involving large numbers of join operations. In order to determine
a reasonable (not necessarily optimal) query plan in a reasonable amount
of time, <productname>PostgreSQL</productname> uses a <firstterm>Genetic
- Query Optimizer</firstterm> (see <xref linkend="geqo">) when the number of joins
- exceeds a threshold (see <xref linkend="guc-geqo-threshold">).
+ Query Optimizer</firstterm> (see <xref linkend="geqo"/>) when the number of joins
+ exceeds a threshold (see <xref linkend="guc-geqo-threshold"/>).
</para>
</note>
</para>
<para>
- If the query uses fewer than <xref linkend="guc-geqo-threshold">
+ If the query uses fewer than <xref linkend="guc-geqo-threshold"/>
relations, a near-exhaustive search is conducted to find the best
join sequence. The planner preferentially considers joins between any
two relations for which there exist a corresponding join clause in the
<para>
When <varname>geqo_threshold</varname> is exceeded, the join
sequences considered are determined by heuristics, as described
- in <xref linkend="geqo">. Otherwise the process is the same.
+ in <xref linkend="geqo"/>. Otherwise the process is the same.
</para>
<para>
<para>
(These kinds of array constants are actually only a special case of
the generic type constants discussed in <xref
- linkend="sql-syntax-constants-generic">. The constant is initially
+ linkend="sql-syntax-constants-generic"/>. The constant is initially
treated as a string and passed to the array input conversion
routine. An explicit type specification might be necessary.)
</para>
expressions; for instance, string literals are single quoted, instead of
double quoted as they would be in an array literal. The <literal>ARRAY</literal>
constructor syntax is discussed in more detail in
- <xref linkend="sql-syntax-array-constructors">.
+ <xref linkend="sql-syntax-array-constructors"/>.
</para>
</sect2>
However, this quickly becomes tedious for large arrays, and is not
helpful if the size of the array is unknown. An alternative method is
- described in <xref linkend="functions-comparisons">. The above
+ described in <xref linkend="functions-comparisons"/>. The above
query could be replaced by:
<programlisting>
WHERE pay_by_quarter[s] = 10000;
</programlisting>
- This function is described in <xref linkend="functions-srf-subscripts">.
+ This function is described in <xref linkend="functions-srf-subscripts"/>.
</para>
<para>
</programlisting>
This and other array operators are further described in
- <xref linkend="functions-array">. It can be accelerated by an appropriate
- index, as described in <xref linkend="indexes-types">.
+ <xref linkend="functions-array"/>. It can be accelerated by an appropriate
+ index, as described in <xref linkend="indexes-types"/>.
</para>
<para>
or backslashes disables this and allows the literal string value
<quote>NULL</quote> to be entered. Also, for backward compatibility with
pre-8.2 versions of <productname>PostgreSQL</productname>, the <xref
- linkend="guc-array-nulls"> configuration parameter can be turned
+ linkend="guc-array-nulls"/> configuration parameter can be turned
<literal>off</literal> to suppress recognition of <literal>NULL</literal> as a NULL.
</para>
with a data type whose input routine also treated backslashes specially,
<type>bytea</type> for example, we might need as many as eight backslashes
in the command to get one backslash into the stored array element.)
- Dollar quoting (see <xref linkend="sql-syntax-dollar-quoting">) can be
+ Dollar quoting (see <xref linkend="sql-syntax-dollar-quoting"/>) can be
used to avoid the need to double backslashes.
</para>
</note>
<tip>
<para>
The <literal>ARRAY</literal> constructor syntax (see
- <xref linkend="sql-syntax-array-constructors">) is often easier to work
+ <xref linkend="sql-syntax-array-constructors"/>) is often easier to work
with than the array-literal syntax when writing array values in SQL
commands. In <literal>ARRAY</literal>, individual element values are written the
same way they would be written when not members of an array.
<para>
In order to function, this module must be loaded via
- <xref linkend="guc-shared-preload-libraries"> in <filename>postgresql.conf</filename>.
+ <xref linkend="guc-shared-preload-libraries"/> in <filename>postgresql.conf</filename>.
</para>
<sect2>
<para>
The <filename>auto_explain</filename> module provides a means for
logging execution plans of slow statements automatically, without
- having to run <xref linkend="sql-explain">
+ having to run <xref linkend="sql-explain"/>
by hand. This is especially helpful for tracking down un-optimized queries
in large applications.
</para>
(You must be superuser to do that.) More typical usage is to preload
it into some or all sessions by including <literal>auto_explain</literal> in
- <xref linkend="guc-session-preload-libraries"> or
- <xref linkend="guc-shared-preload-libraries"> in
+ <xref linkend="guc-session-preload-libraries"/> or
+ <xref linkend="guc-shared-preload-libraries"/> in
<filename>postgresql.conf</filename>. Then you can track unexpectedly slow queries
no matter when they happen. Of course there is a price in overhead for
that.
commands that, when fed back to the server, will recreate the
database in the same state as it was at the time of the dump.
<productname>PostgreSQL</productname> provides the utility program
- <xref linkend="app-pgdump"> for this purpose. The basic usage of this
+ <xref linkend="app-pgdump"/> for this purpose. The basic usage of this
command is:
<synopsis>
pg_dump <replaceable class="parameter">dbname</replaceable> > <replaceable class="parameter">outfile</replaceable>
environment variable <envar>PGUSER</envar>. Remember that
<application>pg_dump</application> connections are subject to the normal
client authentication mechanisms (which are described in <xref
- linkend="client-authentication">).
+ linkend="client-authentication"/>).
</para>
<para>
class="parameter">dbname</replaceable></literal>). <application>psql</application>
supports options similar to <application>pg_dump</application> for specifying
the database server to connect to and the user name to use. See
- the <xref linkend="app-psql"> reference page for more information.
+ the <xref linkend="app-psql"/> reference page for more information.
Non-text file dumps are restored using the <xref
- linkend="app-pgrestore"> utility.
+ linkend="app-pgrestore"/> utility.
</para>
<para>
<para>
After restoring a backup, it is wise to run <xref
- linkend="sql-analyze"> on each
+ linkend="sql-analyze"/> on each
database so the query optimizer has useful statistics;
- see <xref linkend="vacuum-for-statistics">
- and <xref linkend="autovacuum"> for more information.
+ see <xref linkend="vacuum-for-statistics"/>
+ and <xref linkend="autovacuum"/> for more information.
For more advice on how to load large amounts of data
into <productname>PostgreSQL</productname> efficiently, refer to <xref
- linkend="populate">.
+ linkend="populate"/>.
</para>
</sect2>
and it does not dump information about roles or tablespaces
(because those are cluster-wide rather than per-database).
To support convenient dumping of the entire contents of a database
- cluster, the <xref linkend="app-pg-dumpall"> program is provided.
+ cluster, the <xref linkend="app-pg-dumpall"/> program is provided.
<application>pg_dumpall</application> backs up each database in a given
cluster, and also preserves cluster-wide data such as role and
tablespace definitions. The basic usage of this command is:
pg_restore -d <replaceable class="parameter">dbname</replaceable> <replaceable class="parameter">filename</replaceable>
</programlisting>
- See the <xref linkend="app-pgdump"> and <xref
- linkend="app-pgrestore"> reference pages for details.
+ See the <xref linkend="app-pgdump"/> and <xref
+ linkend="app-pgrestore"/> reference pages for details.
</para>
</formalpara>
<para>
An alternative backup strategy is to directly copy the files that
<productname>PostgreSQL</productname> uses to store the data in the database;
- <xref linkend="creating-cluster"> explains where these files
+ <xref linkend="creating-cluster"/> explains where these files
are located. You can use whatever method you prefer
for doing file system backups; for example:
an atomic snapshot of the state of the file system,
but also because of internal buffering within the server).
Information about stopping the server can be found in
- <xref linkend="server-shutdown">. Needless to say, you
+ <xref linkend="server-shutdown"/>. Needless to say, you
also need to shut down the server before restoring the data.
</para>
</listitem>
If simultaneous snapshots are not possible, one option is to shut down
the database server long enough to establish all the frozen snapshots.
Another option is to perform a continuous archiving base backup (<xref
- linkend="backup-base-backup">) because such backups are immune to file
+ linkend="backup-base-backup"/>) because such backups are immune to file
system changes during the backup. This requires enabling continuous
archiving just during the backup process; restore is done using
- continuous archive recovery (<xref linkend="backup-pitr-recovery">).
+ continuous archive recovery (<xref linkend="backup-pitr-recovery"/>).
</para>
<para>
</para>
<para>
- To enable WAL archiving, set the <xref linkend="guc-wal-level">
+ To enable WAL archiving, set the <xref linkend="guc-wal-level"/>
configuration parameter to <literal>replica</literal> or higher,
- <xref linkend="guc-archive-mode"> to <literal>on</literal>,
+ <xref linkend="guc-archive-mode"/> to <literal>on</literal>,
and specify the shell command to use in the <xref
- linkend="guc-archive-command"> configuration parameter. In practice
+ linkend="guc-archive-command"/> configuration parameter. In practice
these settings will always be placed in the
<filename>postgresql.conf</filename> file.
In <varname>archive_command</varname>,
than through SQL operations.
You might wish to keep the configuration files in a location that will
be backed up by your regular file system backup procedures. See
- <xref linkend="runtime-config-file-locations"> for how to relocate the
+ <xref linkend="runtime-config-file-locations"/> for how to relocate the
configuration files.
</para>
where it does so), there could be a long delay between the completion
of a transaction and its safe recording in archive storage. To put
a limit on how old unarchived data can be, you can set
- <xref linkend="guc-archive-timeout"> to force the server to switch
+ <xref linkend="guc-archive-timeout"/> to force the server to switch
to a new WAL segment file at least that often. Note that archived
files that are archived early due to a forced switch are still the same
length as completely full files. It is therefore unwise to set a very
<function>pg_switch_wal</function> if you want to ensure that a
just-finished transaction is archived as soon as possible. Other utility
functions related to WAL management are listed in <xref
- linkend="functions-admin-backup-table">.
+ linkend="functions-admin-backup-table"/>.
</para>
<para>
When <varname>wal_level</varname> is <literal>minimal</literal> some SQL commands
are optimized to avoid WAL logging, as described in <xref
- linkend="populate-pitr">. If archiving or streaming replication were
+ linkend="populate-pitr"/>. If archiving or streaming replication were
turned on during execution of one of these statements, WAL would not
contain enough information for archive recovery. (Crash recovery is
unaffected.) For this reason, <varname>wal_level</varname> can only be changed at
<para>
The easiest way to perform a base backup is to use the
- <xref linkend="app-pgbasebackup"> tool. It can create
+ <xref linkend="app-pgbasebackup"/> tool. It can create
a base backup either as regular files or as a tar archive. If more
- flexibility than <xref linkend="app-pgbasebackup"> can provide is
+ flexibility than <xref linkend="app-pgbasebackup"/> can provide is
required, you can also make a base backup using the low level API
- (see <xref linkend="backup-lowlevel-base-backup">).
+ (see <xref linkend="backup-lowlevel-base-backup"/>).
</para>
<para>
<para>
The backup history file is just a small text file. It contains the
- label string you gave to <xref linkend="app-pgbasebackup">, as well as
+ label string you gave to <xref linkend="app-pgbasebackup"/>, as well as
the starting and ending times and WAL segments of the backup.
If you used the label to identify the associated dump file,
then the archived history file is enough to tell you which dump file to
<para>
The procedure for making a base backup using the low level
APIs contains a few more steps than
- the <xref linkend="app-pgbasebackup"> method, but is relatively
+ the <xref linkend="app-pgbasebackup"/> method, but is relatively
simple. It is very important that these steps are executed in
sequence, and that the success of a step is verified before
proceeding to the next step.
A non-exclusive low level backup is one that allows other
concurrent backups to be running (both those started using
the same backup API and those started using
- <xref linkend="app-pgbasebackup">).
+ <xref linkend="app-pgbasebackup"/>).
</para>
<para>
<orderedlist>
required for the checkpoint will be spread out over a significant
period of time, by default half your inter-checkpoint interval
(see the configuration parameter
- <xref linkend="guc-checkpoint-completion-target">). This is
+ <xref linkend="guc-checkpoint-completion-target"/>). This is
usually what you want, because it minimizes the impact on query
processing. If you want to start the backup as soon as
possible, change the second parameter to <literal>true</literal>, which will
<application>pg_dumpall</application>). It is neither
necessary nor desirable to stop normal operation of the database
while you do this. See
- <xref linkend="backup-lowlevel-base-backup-data"> for things to
+ <xref linkend="backup-lowlevel-base-backup-data"/> for things to
consider during this backup.
</para>
</listitem>
required for the checkpoint will be spread out over a significant
period of time, by default half your inter-checkpoint interval
(see the configuration parameter
- <xref linkend="guc-checkpoint-completion-target">). This is
+ <xref linkend="guc-checkpoint-completion-target"/>). This is
usually what you want, because it minimizes the impact on query
processing. If you want to start the backup as soon as
possible, use:
<application>pg_dumpall</application>). It is neither
necessary nor desirable to stop normal operation of the database
while you do this. See
- <xref linkend="backup-lowlevel-base-backup-data"> for things to
+ <xref linkend="backup-lowlevel-base-backup-data"/> for things to
consider during this backup.
</para>
<para>
<filename>pg_snapshots/</filename>, <filename>pg_stat_tmp/</filename>,
and <filename>pg_subtrans/</filename> (but not the directories themselves) can be
omitted from the backup as they will be initialized on postmaster startup.
- If <xref linkend="guc-stats-temp-directory"> is set and is under the data
+ If <xref linkend="guc-stats-temp-directory"/> is set and is under the data
directory then the contents of that directory can also be omitted.
</para>
<listitem>
<para>
Create a recovery command file <filename>recovery.conf</filename> in the cluster
- data directory (see <xref linkend="recovery-config">). You might
+ data directory (see <xref linkend="recovery-config"/>). You might
also want to temporarily modify <filename>pg_hba.conf</filename> to prevent
ordinary users from connecting until you are sure the recovery was successful.
</para>
at the start of recovery for a file named something like
<filename>00000001.history</filename>. This is also normal and does not
indicate a problem in simple recovery situations; see
- <xref linkend="backup-timelines"> for discussion.
+ <xref linkend="backup-timelines"/> for discussion.
</para>
<para>
<para>
As with base backups, the easiest way to produce a standalone
- hot backup is to use the <xref linkend="app-pgbasebackup">
+ hot backup is to use the <xref linkend="app-pgbasebackup"/>
tool. If you include the <literal>-X</literal> parameter when calling
it, all the write-ahead log required to use the backup will be
included in the backup automatically, and no special action is
<tip>
<para>
When using an <varname>archive_command</varname> script, it's desirable
- to enable <xref linkend="guc-logging-collector">.
+ to enable <xref linkend="guc-logging-collector"/>.
Any messages written to <systemitem>stderr</systemitem> from the script will then
appear in the database server log, allowing complex configurations to
be diagnosed easily if they fail.
<itemizedlist>
<listitem>
<para>
- If a <xref linkend="sql-createdatabase">
+ If a <xref linkend="sql-createdatabase"/>
command is executed while a base backup is being taken, and then
the template database that the <command>CREATE DATABASE</command> copied
is modified while the base backup is still in progress, it is
<listitem>
<para>
- <xref linkend="sql-createtablespace">
+ <xref linkend="sql-createtablespace"/>
commands are WAL-logged with the literal absolute path, and will
therefore be replayed as tablespace creations with the same
absolute path. This might be undesirable if the log is being
your system hardware and software, the risk of partial writes might
be small enough to ignore, in which case you can significantly
reduce the total volume of archived logs by turning off page
- snapshots using the <xref linkend="guc-full-page-writes">
- parameter. (Read the notes and warnings in <xref linkend="wal">
+ snapshots using the <xref linkend="guc-full-page-writes"/>
+ parameter. (Read the notes and warnings in <xref linkend="wal"/>
before you do so.) Turning off page snapshots does not prevent
use of the logs for PITR operations. An area for future
development is to compress archived WAL data by removing
<para>
The maximum number of registered background workers is limited by
- <xref linkend="guc-max-worker-processes">.
+ <xref linkend="guc-max-worker-processes"/>.
</para>
</chapter>
<para>
The core <productname>PostgreSQL</productname> distribution
includes the <acronym>BRIN</acronym> operator classes shown in
- <xref linkend="brin-builtin-opclasses-table">.
+ <xref linkend="brin-builtin-opclasses-table"/>.
</para>
<para>
To write an operator class for a data type that implements a totally
ordered set, it is possible to use the minmax support procedures
alongside the corresponding operators, as shown in
- <xref linkend="brin-extensibility-minmax-table">.
+ <xref linkend="brin-extensibility-minmax-table"/>.
All operator class members (procedures and operators) are mandatory.
</para>
To write an operator class for a complex data type which has values
included within another type, it's possible to use the inclusion support
procedures alongside the corresponding operators, as shown
- in <xref linkend="brin-extensibility-inclusion-table">. It requires
+ in <xref linkend="brin-extensibility-inclusion-table"/>. It requires
only a single additional function, which can be written in any language.
More functions can be defined for additional functionality. All operators
are optional. Some operators require other operators, as shown as
additional data types to be supported by defining extra sets
of operators. Inclusion operator class operator strategies are dependent
on another operator strategy as shown in
- <xref linkend="brin-extensibility-inclusion-table">, or the same
+ <xref linkend="brin-extensibility-inclusion-table"/>, or the same
operator strategy as themselves. They require the dependency
operator to be defined with the <literal>STORAGE</literal> data type as the
left-hand-side argument and the other supported data type to be the
<title>Overview</title>
<para>
- <xref linkend="catalog-table"> lists the system catalogs.
+ <xref linkend="catalog-table"/> lists the system catalogs.
More detailed documentation of each catalog follows below.
</para>
<para>
New aggregate functions are registered with the <xref
- linkend="sql-createaggregate">
- command. See <xref linkend="xaggr"> for more information about
+ linkend="sql-createaggregate"/>
+ command. See <xref linkend="xaggr"/> for more information about
writing aggregate functions and the meaning of the transition
functions, etc.
</para>
relation access methods. There is one row for each access method supported
by the system.
Currently, only indexes have access methods. The requirements for index
- access methods are discussed in detail in <xref linkend="indexam">.
+ access methods are discussed in detail in <xref linkend="indexam"/>.
</para>
<table>
methods. That data is now only directly visible at the C code level.
However, <function>pg_index_column_has_property()</function> and related
functions have been added to allow SQL queries to inspect index access
- method properties; see <xref linkend="functions-info-catalog-table">.
+ method properties; see <xref linkend="functions-info-catalog-table"/>.
</para>
</note>
<entry>
<structfield>attstattarget</structfield> controls the level of detail
of statistics accumulated for this column by
- <xref linkend="sql-analyze">.
+ <xref linkend="sql-analyze"/>.
A zero value indicates that no statistics should be collected.
A negative value says to use the system default statistics target.
The exact meaning of positive values is data type-dependent.
</para>
<para>
- <xref linkend="user-manag"> contains detailed information about user and
+ <xref linkend="user-manag"/> contains detailed information about user and
privilege management.
</para>
<entry><type>bool</type></entry>
<entry>
Role bypasses every row level security policy, see
- <xref linkend="ddl-rowsecurity"> for more information.
+ <xref linkend="ddl-rowsecurity"/> for more information.
</entry>
</row>
<entry></entry>
<entry>
Access privileges; see
- <xref linkend="sql-grant"> and
- <xref linkend="sql-revoke">
+ <xref linkend="sql-grant"/> and
+ <xref linkend="sql-revoke"/>
for details
</entry>
</row>
The catalog <structname>pg_collation</structname> describes the
available collations, which are essentially mappings from an SQL
name to operating system locale categories.
- See <xref linkend="collation"> for more information.
+ See <xref linkend="collation"/> for more information.
</para>
<table>
<para>
The catalog <structname>pg_conversion</structname> describes
- encoding conversion procedures. See <xref linkend="sql-createconversion">
+ encoding conversion procedures. See <xref linkend="sql-createconversion"/>
for more information.
</para>
<para>
The catalog <structname>pg_database</structname> stores information about
the available databases. Databases are created with the <xref
- linkend="sql-createdatabase"> command.
- Consult <xref linkend="managing-databases"> for details about the meaning
+ linkend="sql-createdatabase"/> command.
+ Consult <xref linkend="managing-databases"/> for details about the meaning
of some of the parameters.
</para>
<entry></entry>
<entry>
Access privileges; see
- <xref linkend="sql-grant"> and
- <xref linkend="sql-revoke">
+ <xref linkend="sql-grant"/> and
+ <xref linkend="sql-revoke"/>
for details
</entry>
</row>
<para>
The catalog <structname>pg_description</structname> stores optional descriptions
(comments) for each database object. Descriptions can be manipulated
- with the <xref linkend="sql-comment"> command and viewed with
+ with the <xref linkend="sql-comment"/> command and viewed with
<application>psql</application>'s <literal>\d</literal> commands.
Descriptions of many built-in system objects are provided in the initial
contents of <structname>pg_description</structname>.
<para>
The catalog <structname>pg_event_trigger</structname> stores event triggers.
- See <xref linkend="event-triggers"> for more information.
+ See <xref linkend="event-triggers"/> for more information.
</para>
<table>
<entry><type>char</type></entry>
<entry></entry>
<entry>
- Controls in which <xref linkend="guc-session-replication-role"> modes
+ Controls in which <xref linkend="guc-session-replication-role"/> modes
the event trigger fires.
<literal>O</literal> = trigger fires in <quote>origin</quote> and <quote>local</quote> modes,
<literal>D</literal> = trigger is disabled,
<para>
The catalog <structname>pg_extension</structname> stores information
- about the installed extensions. See <xref linkend="extend-extensions">
+ about the installed extensions. See <xref linkend="extend-extensions"/>
for details about extensions.
</para>
<entry></entry>
<entry>
Access privileges; see
- <xref linkend="sql-grant"> and
- <xref linkend="sql-revoke">
+ <xref linkend="sql-grant"/> and
+ <xref linkend="sql-revoke"/>
for details
</entry>
</row>
<entry></entry>
<entry>
Access privileges; see
- <xref linkend="sql-grant"> and
- <xref linkend="sql-revoke">
+ <xref linkend="sql-grant"/> and
+ <xref linkend="sql-revoke"/>
for details
</entry>
</row>
<entry></entry>
<entry>
The initial access privileges; see
- <xref linkend="sql-grant"> and
- <xref linkend="sql-revoke">
+ <xref linkend="sql-grant"/> and
+ <xref linkend="sql-revoke"/>
for details
</entry>
</row>
<para>
The catalog <structname>pg_language</structname> registers
languages in which you can write functions or stored procedures.
- See <xref linkend="sql-createlanguage">
- and <xref linkend="xplang"> for more information about language handlers.
+ See <xref linkend="sql-createlanguage"/>
+ and <xref linkend="xplang"/> for more information about language handlers.
</para>
<table>
<entry>
This references a function that is responsible for executing
<quote>inline</quote> anonymous code blocks
- (<xref linkend="sql-do"> blocks).
+ (<xref linkend="sql-do"/> blocks).
Zero if inline blocks are not supported.
</entry>
</row>
<entry></entry>
<entry>
Access privileges; see
- <xref linkend="sql-grant"> and
- <xref linkend="sql-revoke">
+ <xref linkend="sql-grant"/> and
+ <xref linkend="sql-revoke"/>
for details
</entry>
</row>
<entry></entry>
<entry>
Access privileges; see
- <xref linkend="sql-grant"> and
- <xref linkend="sql-revoke">
+ <xref linkend="sql-grant"/> and
+ <xref linkend="sql-revoke"/>
for details
</entry>
</row>
<entry></entry>
<entry>
Access privileges; see
- <xref linkend="sql-grant"> and
- <xref linkend="sql-revoke">
+ <xref linkend="sql-grant"/> and
+ <xref linkend="sql-revoke"/>
for details
</entry>
</row>
</para>
<para>
- Operator classes are described at length in <xref linkend="xindex">.
+ Operator classes are described at length in <xref linkend="xindex"/>.
</para>
<table>
<para>
The catalog <structname>pg_operator</structname> stores information about operators.
- See <xref linkend="sql-createoperator">
- and <xref linkend="xoper"> for more information.
+ See <xref linkend="sql-createoperator"/>
+ and <xref linkend="xoper"/> for more information.
</para>
<table>
</para>
<para>
- Operator families are described at length in <xref linkend="xindex">.
+ Operator families are described at length in <xref linkend="xindex"/>.
</para>
<table>
<para>
The catalog <structname>pg_proc</structname> stores information about functions (or procedures).
- See <xref linkend="sql-createfunction">
- and <xref linkend="xfunc"> for more information.
+ See <xref linkend="sql-createfunction"/>
+ and <xref linkend="xfunc"/> for more information.
</para>
<para>
<entry><type>float4</type></entry>
<entry></entry>
<entry>Estimated execution cost (in units of
- <xref linkend="guc-cpu-operator-cost">); if <structfield>proretset</structfield>,
+ <xref linkend="guc-cpu-operator-cost"/>); if <structfield>proretset</structfield>,
this is cost per row returned</entry>
</row>
<entry><type>regproc</type></entry>
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
<entry>Calls to this function can be simplified by this other function
- (see <xref linkend="xfunc-transform-functions">)</entry>
+ (see <xref linkend="xfunc-transform-functions"/>)</entry>
</row>
<row>
<entry></entry>
<entry>
Access privileges; see
- <xref linkend="sql-grant"> and
- <xref linkend="sql-revoke">
+ <xref linkend="sql-grant"/> and
+ <xref linkend="sql-revoke"/>
for details
</entry>
</row>
<para>
The catalog <structname>pg_publication</structname> contains all
publications created in the database. For more on publications see
- <xref linkend="logical-replication-publication">.
+ <xref linkend="logical-replication-publication"/>.
</para>
<table>
<para>
The catalog <structname>pg_publication_rel</structname> contains the
mapping between relations and publications in the database. This is a
- many-to-many mapping. See also <xref linkend="view-pg-publication-tables">
+ many-to-many mapping. See also <xref linkend="view-pg-publication-tables"/>
for a more user-friendly view of this information.
</para>
<para>
The <structname>pg_replication_origin</structname> catalog contains
all replication origins created. For more on replication origins
- see <xref linkend="replication-origins">.
+ see <xref linkend="replication-origins"/>.
</para>
<table>
<entry><type>char</type></entry>
<entry></entry>
<entry>
- Controls in which <xref linkend="guc-session-replication-role"> modes
+ Controls in which <xref linkend="guc-session-replication-role"/> modes
the rule fires.
<literal>O</literal> = rule fires in <quote>origin</quote> and <quote>local</quote> modes,
<literal>D</literal> = rule is disabled,
<para>
The catalog <structname>pg_seclabel</structname> stores security
labels on database objects. Security labels can be manipulated
- with the <xref linkend="sql-security-label"> command. For an easier
- way to view security labels, see <xref linkend="view-pg-seclabels">.
+ with the <xref linkend="sql-security-label"/> command. For an easier
+ way to view security labels, see <xref linkend="view-pg-seclabels"/>.
</para>
<para>
<para>
The catalog <structname>pg_shdescription</structname> stores optional
descriptions (comments) for shared database objects. Descriptions can be
- manipulated with the <xref linkend="sql-comment"> command and viewed with
+ manipulated with the <xref linkend="sql-comment"/> command and viewed with
<application>psql</application>'s <literal>\d</literal> commands.
</para>
<para>
The catalog <structname>pg_shseclabel</structname> stores security
labels on shared database objects. Security labels can be manipulated
- with the <xref linkend="sql-security-label"> command. For an easier
- way to view security labels, see <xref linkend="view-pg-seclabels">.
+ with the <xref linkend="sql-security-label"/> command. For an easier
+ way to view security labels, see <xref linkend="view-pg-seclabels"/>.
</para>
<para>
<para>
The catalog <structname>pg_statistic</structname> stores
statistical data about the contents of the database. Entries are
- created by <xref linkend="sql-analyze">
+ created by <xref linkend="sql-analyze"/>
and subsequently used by the query planner. Note that all the
statistical data is inherently approximate, even assuming that it
is up-to-date.
The catalog <structname>pg_statistic_ext</structname>
holds extended planner statistics.
Each row in this catalog corresponds to a <firstterm>statistics object</firstterm>
- created with <xref linkend="sql-createstatistics">.
+ created with <xref linkend="sql-createstatistics"/>.
</para>
<table>
<para>
The catalog <structname>pg_subscription</structname> contains all existing
logical replication subscriptions. For more information about logical
- replication see <xref linkend="logical-replication">.
+ replication see <xref linkend="logical-replication"/>.
</para>
<para>
<entry></entry>
<entry>Array of subscribed publication names. These reference the
publications on the publisher server. For more on publications
- see <xref linkend="logical-replication-publication">.
+ see <xref linkend="logical-replication-publication"/>.
</entry>
</row>
</tbody>
<entry></entry>
<entry>
Access privileges; see
- <xref linkend="sql-grant"> and
- <xref linkend="sql-revoke">
+ <xref linkend="sql-grant"/> and
+ <xref linkend="sql-revoke"/>
for details
</entry>
</row>
<para>
The catalog <structname>pg_transform</structname> stores information about
transforms, which are a mechanism to adapt data types to procedural
- languages. See <xref linkend="sql-createtransform"> for more information.
+ languages. See <xref linkend="sql-createtransform"/> for more information.
</para>
<table>
<para>
The catalog <structname>pg_trigger</structname> stores triggers on tables
and views.
- See <xref linkend="sql-createtrigger">
+ See <xref linkend="sql-createtrigger"/>
for more information.
</para>
<entry><type>char</type></entry>
<entry></entry>
<entry>
- Controls in which <xref linkend="guc-session-replication-role"> modes
+ Controls in which <xref linkend="guc-session-replication-role"/> modes
the trigger fires.
<literal>O</literal> = trigger fires in <quote>origin</quote> and <quote>local</quote> modes,
<literal>D</literal> = trigger is disabled,
<para>
<productname>PostgreSQL</productname>'s text search features are
- described at length in <xref linkend="textsearch">.
+ described at length in <xref linkend="textsearch"/>.
</para>
<table>
<para>
<productname>PostgreSQL</productname>'s text search features are
- described at length in <xref linkend="textsearch">.
+ described at length in <xref linkend="textsearch"/>.
</para>
<table>
<para>
<productname>PostgreSQL</productname>'s text search features are
- described at length in <xref linkend="textsearch">.
+ described at length in <xref linkend="textsearch"/>.
</para>
<table>
<para>
<productname>PostgreSQL</productname>'s text search features are
- described at length in <xref linkend="textsearch">.
+ described at length in <xref linkend="textsearch"/>.
</para>
<table>
<para>
<productname>PostgreSQL</productname>'s text search features are
- described at length in <xref linkend="textsearch">.
+ described at length in <xref linkend="textsearch"/>.
</para>
<table>
<para>
The catalog <structname>pg_type</structname> stores information about data
types. Base types and enum types (scalar types) are created with
- <xref linkend="sql-createtype">, and
+ <xref linkend="sql-createtype"/>, and
domains with
- <xref linkend="sql-createdomain">.
+ <xref linkend="sql-createdomain"/>.
A composite type is automatically created for each table in the database, to
represent the row structure of the table. It is also possible to create
composite types with <command>CREATE TYPE AS</command>.
<structfield>typcategory</structfield> is an arbitrary classification
of data types that is used by the parser to determine which implicit
casts should be <quote>preferred</quote>.
- See <xref linkend="catalog-typcategory-table">.
+ See <xref linkend="catalog-typcategory-table"/>.
</entry>
</row>
<entry></entry>
<entry>
Access privileges; see
- <xref linkend="sql-grant"> and
- <xref linkend="sql-revoke">
+ <xref linkend="sql-grant"/> and
+ <xref linkend="sql-revoke"/>
for details
</entry>
</row>
</table>
<para>
- <xref linkend="catalog-typcategory-table"> lists the system-defined values
+ <xref linkend="catalog-typcategory-table"/> lists the system-defined values
of <structfield>typcategory</structfield>. Any future additions to this list will
also be upper-case ASCII letters. All other ASCII characters are reserved
for user-defined categories.
</para>
<para>
- The information schema (<xref linkend="information-schema">) provides
+ The information schema (<xref linkend="information-schema"/>) provides
an alternative set of views which overlap the functionality of the system
views. Since the information schema is SQL-standard whereas the views
described here are <productname>PostgreSQL</productname>-specific,
</para>
<para>
- <xref linkend="view-table"> lists the system views described here.
+ <xref linkend="view-table"/> lists the system views described here.
More detailed documentation of each view follows below.
There are some additional views that provide access to the results of
the statistics collector; they are described in <xref
- linkend="monitoring-stats-views-table">.
+ linkend="monitoring-stats-views-table"/>.
</para>
<para>
be used by software packages that want to interface to
<productname>PostgreSQL</productname> to facilitate finding the required header
files and libraries. It provides the same basic information as the
- <xref linkend="app-pgconfig"> <productname>PostgreSQL</productname> client
+ <xref linkend="app-pgconfig"
/> <productname>PostgreSQL</productname> client
application.
</para>
<itemizedlist>
<listitem>
<para>
- via the <xref linkend="sql-declare">
+ via the <xref linkend="sql-declare"/>
statement in SQL
</para>
</listitem>
<listitem>
<para>
via the Bind message in the frontend/backend protocol, as
- described in <xref linkend="protocol-flow-ext-query">
+ described in <xref linkend="protocol-flow-ext-query"/>
</para>
</listitem>
<listitem>
<para>
via the Server Programming Interface (SPI), as described in
- <xref linkend="spi-interface">
+ <xref linkend="spi-interface"/>
</para>
</listitem>
</itemizedlist>
</para>
<para>
- See <xref linkend="config-setting"> for more information about the various
+ See <xref linkend="config-setting"/> for more information about the various
ways to change run-time parameters.
</para>
</para>
<para>
- See <xref linkend="client-authentication"> for more information about
+ See <xref linkend="client-authentication"/> for more information about
client authentication configuration.
</para>
</sect1>
<para>
The view <structname>pg_locks</structname> provides access to
information about the locks held by active processes within the
- database server. See <xref linkend="mvcc"> for more discussion
+ database server. See <xref linkend="mvcc"/> for more discussion
of locking.
</para>
<entry><type>text</type></entry>
<entry></entry>
<entry>Name of the lock mode held or desired by this process (see <xref
- linkend="locking-tables"> and <xref linkend="xact-serializable">)</entry>
+ linkend="locking-tables"/> and <xref linkend="xact-serializable"/>)</entry>
</row>
<row>
<entry><structfield>granted</structfield></entry>
queues, nor information about which processes are parallel workers running
on behalf of which other client sessions. It is better to use
the <function>pg_blocking_pids()</function> function
- (see <xref linkend="functions-info-session-table">) to identify which
+ (see <xref linkend="functions-info-session-table"/>) to identify which
process(es) a waiting process is blocked behind.
</para>
<para>
The <structname>pg_prepared_statements</structname> view displays
all the prepared statements that are available in the current
- session. See <xref linkend="sql-prepare"> for more information about prepared
+ session. See <xref linkend="sql-prepare"/> for more information about prepared
statements.
</para>
<structname>pg_prepared_statements</structname> contains one row
for each prepared statement. Rows are added to the view when a new
prepared statement is created and removed when a prepared statement
- is released (for example, via the <xref linkend="sql-deallocate"> command).
+ is released (for example, via the <xref linkend="sql-deallocate"/> command).
</para>
<table>
<para>
The view <structname>pg_prepared_xacts</structname> displays
information about transactions that are currently prepared for two-phase
- commit (see <xref linkend="sql-prepare-transaction"> for details).
+ commit (see <xref linkend="sql-prepare-transaction"/> for details).
</para>
<para>
The <structname>pg_replication_origin_status</structname> view
contains information about how far replay for a certain origin has
progressed. For more on replication origins
- see <xref linkend="replication-origins">.
+ see <xref linkend="replication-origins"/>.
</para>
<table>
<para>
For more on replication slots,
- see <xref linkend="streaming-replication-slots"> and <xref linkend="logicaldecoding">.
+ see <xref linkend="streaming-replication-slots"/> and <xref linkend="logicaldecoding"/>.
</para>
<table>
<entry></entry>
<entry>
Role bypasses every row level security policy, see
- <xref linkend="ddl-rowsecurity"> for more information.
+ <xref linkend="ddl-rowsecurity"/> for more information.
</entry>
</row>
<para>
The view <structname>pg_settings</structname> provides access to
run-time parameters of the server. It is essentially an alternative
- interface to the <xref linkend="sql-show">
- and <xref linkend="sql-set"> commands.
+ interface to the <xref linkend="sql-show"/>
+ and <xref linkend="sql-set"/> commands.
It also provides access to some facts about each parameter that are
not directly available from <command>SHOW</command>, such as minimum and
maximum values.
</variablelist>
<para>
- See <xref linkend="config-setting"> for more information about the various
+ See <xref linkend="config-setting"/> for more information about the various
ways to change these parameters.
</para>
The <structname>pg_settings</structname> view cannot be inserted into or
deleted from, but it can be updated. An <command>UPDATE</command> applied
to a row of <structname>pg_settings</structname> is equivalent to executing
- the <xref linkend="sql-set"> command on that named
+ the <xref linkend="sql-set"/> command on that named
parameter. The change only affects the value used by the current
session. If an <command>UPDATE</command> is issued within a transaction
that is later aborted, the effects of the <command>UPDATE</command> command
<entry></entry>
<entry>
User bypasses every row level security policy, see
- <xref linkend="ddl-rowsecurity"> for more information.
+ <xref linkend="ddl-rowsecurity"/> for more information.
</entry>
</row>
The maximum number of entries in the array fields can be controlled on a
column-by-column basis using the <command>ALTER TABLE SET STATISTICS</command>
command, or globally by setting the
- <xref linkend="guc-default-statistics-target"> run-time parameter.
+ <xref linkend="guc-default-statistics-target"/> run-time parameter.
</para>
</sect1>
The view <structname>pg_timezone_abbrevs</structname> provides a list
of time zone abbreviations that are currently recognized by the datetime
input routines. The contents of this view change when the
- <xref linkend="guc-timezone-abbreviations"> run-time parameter is modified.
+ <xref linkend="guc-timezone-abbreviations"/> run-time parameter is modified.
</para>
<table>
<para>
While most timezone abbreviations represent fixed offsets from UTC,
there are some that have historically varied in value
- (see <xref linkend="datetime-config-files"> for more information).
+ (see <xref linkend="datetime-config-files"/> for more information).
In such cases this view presents their current meaning.
</para>
<entry><type>bool</type></entry>
<entry>
User bypasses every row level security policy, see
- <xref linkend="ddl-rowsecurity"> for more information.
+ <xref linkend="ddl-rowsecurity"/> for more information.
</entry>
</row>
Using the locale features of the operating system to provide
locale-specific collation order, number formatting, translated
messages, and other aspects.
- This is covered in <xref linkend="locale"> and
- <xref linkend="collation">.
+ This is covered in <xref linkend="locale"/> and
+ <xref linkend="collation"/>.
</para>
</listitem>
Providing a number of different character sets to support storing text
in all kinds of languages, and providing character set translation
between client and server.
- This is covered in <xref linkend="multibyte">.
+ This is covered in <xref linkend="multibyte"/>.
</para>
</listitem>
</itemizedlist>
the sort order of indexes, so they must be kept fixed, or indexes on
text columns would become corrupt.
(But you can alleviate this restriction using collations, as discussed
- in <xref linkend="collation">.)
+ in <xref linkend="collation"/>.)
The default values for these
categories are determined when <command>initdb</command> is run, and
those values are used when new databases are created, unless
The other locale categories can be changed whenever desired
by setting the server configuration parameters
that have the same name as the locale categories (see <xref
- linkend="runtime-config-client-format"> for details). The values
+ linkend="runtime-config-client-format"/> for details). The values
that are chosen by <command>initdb</command> are actually only written
into the configuration file <filename>postgresql.conf</filename> to
serve as defaults when the server is started. If you remove these
with <literal>LIKE</literal> clauses under a non-C locale, several custom
operator classes exist. These allow the creation of an index that
performs a strict character-by-character comparison, ignoring
- locale comparison rules. Refer to <xref linkend="indexes-opclass">
+ locale comparison rules. Refer to <xref linkend="indexes-opclass"/>
for more information. Another approach is to create indexes using
the <literal>C</literal> collation, as discussed in
- <xref linkend="collation">.
+ <xref linkend="collation"/>.
</para>
</sect2>
<productname>PostgreSQL</productname> speak their preferred language well.
If messages in your language are currently not available or not fully
translated, your assistance would be appreciated. If you want to
- help, refer to <xref linkend="nls"> or write to the developers'
+ help, refer to <xref linkend="nls"/> or write to the developers'
mailing list.
</para>
</sect2>
these under one concept than to create another infrastructure for
setting <symbol>LC_CTYPE</symbol> per expression.) Also,
a <literal>libc</literal> collation
- is tied to a character set encoding (see <xref linkend="multibyte">).
+ is tied to a character set encoding (see <xref linkend="multibyte"/>).
The same collation name may exist for different encodings.
</para>
for <symbol>LC_COLLATE</symbol> and <symbol>LC_CTYPE</symbol>, or if new
locales are installed in the operating system after the database system
was initialized, then a new collation may be created using
- the <xref linkend="sql-createcollation"> command.
+ the <xref linkend="sql-createcollation"/> command.
New operating system locales can also be imported en masse using
the <link linkend="functions-admin-collation"><function>pg_import_system_collations()</function></link> function.
</para>
<para>
If the standard and predefined collations are not sufficient, users can
create their own collation objects using the SQL
- command <xref linkend="sql-createcollation">.
+ command <xref linkend="sql-createcollation"/>.
</para>
<para>
defined in the operating system when the database instance is
initialized, it is not often necessary to manually create new ones.
Reasons might be if a different naming system is desired (in which case
- see also <xref linkend="collation-copy">) or if the operating system has
+ see also <xref linkend="collation-copy"/>) or if the operating system has
been upgraded to provide new locale definitions (in which case see
also <link linkend="functions-admin-collation"><function>pg_import_system_collations()</function></link>).
</para>
<title>Copying Collations</title>
<para>
- The command <xref linkend="sql-createcollation"> can also be used to
+ The command <xref linkend="sql-createcollation"/> can also be used to
create a new collation from an existing collation, which can be useful to
be able to use operating-system-independent collation names in
applications, create compatibility names, or use an ICU-provided collation
<title>Supported Character Sets</title>
<para>
- <xref linkend="charset-table"> shows the character sets available
+ <xref linkend="charset-table"/> shows the character sets available
for use in <productname>PostgreSQL</productname>.
</para>
database. When copying any other database, the encoding and locale
settings cannot be changed from those of the source database, because
that might result in corrupt data. For more information see
- <xref linkend="manage-ag-templatedbs">.
+ <xref linkend="manage-ag-templatedbs"/>.
</para>
<para>
character set combinations. The conversion information is stored in the
<literal>pg_conversion</literal> system catalog. <productname>PostgreSQL</productname>
comes with some predefined conversions, as shown in <xref
- linkend="multibyte-translation-table">. You can create a new
+ linkend="multibyte-translation-table"/>. You can create a new
conversion using the SQL command <command>CREATE CONVERSION</command>.
</para>
<listitem>
<para>
- <application>libpq</application> (<xref linkend="libpq-control">) has functions to control the client encoding.
+ <application>libpq</application> (<xref linkend="libpq-control"/>) has functions to control the client encoding.
</para>
</listitem>
<listitem>
<para>
Using the configuration variable <xref
- linkend="guc-client-encoding">. If the
+ linkend="guc-client-encoding"/>. If the
<varname>client_encoding</varname> variable is set, that client
encoding is automatically selected when a connection to the
server is made. (This can subsequently be overridden using any
wants to connect as, much the same way one logs into a Unix computer
as a particular user. Within the SQL environment the active database
user name determines access privileges to database objects — see
- <xref linkend="user-manag"> for more information. Therefore, it is
+ <xref linkend="user-manag"/> for more information. Therefore, it is
essential to restrict which database users can connect.
</para>
<note>
<para>
- As explained in <xref linkend="user-manag">,
+ As explained in <xref linkend="user-manag"/>,
<productname>PostgreSQL</productname> actually does privilege
management in terms of <quote>roles</quote>. In this chapter, we
consistently use <firstterm>database user</firstterm> to mean <quote>role with the
<filename>pg_hba.conf</filename> file is installed when the data
directory is initialized by <command>initdb</command>. It is
possible to place the authentication configuration file elsewhere,
- however; see the <xref linkend="guc-hba-file"> configuration parameter.
+ however; see the <xref linkend="guc-hba-file"/> configuration parameter.
</para>
<para>
<para>
Remote TCP/IP connections will not be possible unless
the server is started with an appropriate value for the
- <xref linkend="guc-listen-addresses"> configuration parameter,
+ <xref linkend="guc-listen-addresses"/> configuration parameter,
since the default behavior is to listen for TCP/IP connections
only on the local loopback address <literal>localhost</literal>.
</para>
To make use of this option the server must be built with
<acronym>SSL</acronym> support. Furthermore,
<acronym>SSL</acronym> must be enabled
- by setting the <xref linkend="guc-ssl"> configuration parameter (see
- <xref linkend="ssl-tcp"> for more information).
+ by setting the <xref linkend="guc-ssl"/> configuration parameter (see
+ <xref linkend="ssl-tcp"/> for more information).
Otherwise, the <literal>hostssl</literal> record is ignored except for
logging a warning that it cannot match any connections.
</para>
<para>
Specifies the authentication method to use when a connection matches
this record. The possible choices are summarized here; details
- are in <xref linkend="auth-methods">.
+ are in <xref linkend="auth-methods"/>.
<variablelist>
<varlistentry>
<productname>PostgreSQL</productname> database server to login as
any <productname>PostgreSQL</productname> user they wish,
without the need for a password or any other authentication. See <xref
- linkend="auth-trust"> for details.
+ linkend="auth-trust"/> for details.
</para>
</listitem>
</varlistentry>
<listitem>
<para>
Perform SCRAM-SHA-256 authentication to verify the user's
- password. See <xref linkend="auth-password"> for details.
+ password. See <xref linkend="auth-password"/> for details.
</para>
</listitem>
</varlistentry>
<listitem>
<para>
Perform SCRAM-SHA-256 or MD5 authentication to verify the
- user's password. See <xref linkend="auth-password">
+ user's password. See <xref linkend="auth-password"/>
for details.
</para>
</listitem>
authentication.
Since the password is sent in clear text over the
network, this should not be used on untrusted networks.
- See <xref linkend="auth-password"> for details.
+ See <xref linkend="auth-password"/> for details.
</para>
</listitem>
</varlistentry>
<para>
Use GSSAPI to authenticate the user. This is only
available for TCP/IP connections. See <xref
- linkend="gssapi-auth"> for details.
+ linkend="gssapi-auth"/> for details.
</para>
</listitem>
</varlistentry>
<para>
Use SSPI to authenticate the user. This is only
available on Windows. See <xref
- linkend="sspi-auth"> for details.
+ linkend="sspi-auth"/> for details.
</para>
</listitem>
</varlistentry>
Ident authentication can only be used on TCP/IP
connections. When specified for local connections, peer
authentication will be used instead.
- See <xref linkend="auth-ident"> for details.
+ See <xref linkend="auth-ident"/> for details.
</para>
</listitem>
</varlistentry>
Obtain the client's operating system user name from the operating
system and check if it matches the requested database user name.
This is only available for local connections.
- See <xref linkend="auth-peer"> for details.
+ See <xref linkend="auth-peer"/> for details.
</para>
</listitem>
</varlistentry>
<listitem>
<para>
Authenticate using an <acronym>LDAP</acronym> server. See <xref
- linkend="auth-ldap"> for details.
+ linkend="auth-ldap"/> for details.
</para>
</listitem>
</varlistentry>
<listitem>
<para>
Authenticate using a RADIUS server. See <xref
- linkend="auth-radius"> for details.
+ linkend="auth-radius"/> for details.
</para>
</listitem>
</varlistentry>
<listitem>
<para>
Authenticate using SSL client certificates. See
- <xref linkend="auth-cert"> for details.
+ <xref linkend="auth-cert"/> for details.
</para>
</listitem>
</varlistentry>
<para>
Authenticate using the Pluggable Authentication Modules
(PAM) service provided by the operating system. See <xref
- linkend="auth-pam"> for details.
+ linkend="auth-pam"/> for details.
</para>
</listitem>
</varlistentry>
<listitem>
<para>
Authenticate using the BSD Authentication service provided by the
- operating system. See <xref linkend="auth-bsd"> for details.
+ operating system. See <xref linkend="auth-bsd"/> for details.
</para>
</listitem>
</varlistentry>
<para>
Some examples of <filename>pg_hba.conf</filename> entries are shown in
- <xref linkend="example-pg-hba.conf">. See the next section for details on the
+ <xref linkend="example-pg-hba.conf"/>. See the next section for details on the
different authentication methods.
</para>
<filename>pg_ident.conf</filename><indexterm><primary>pg_ident.conf</primary></indexterm>
and is stored in the
cluster's data directory. (It is possible to place the map file
- elsewhere, however; see the <xref linkend="guc-ident-file">
+ elsewhere, however; see the <xref linkend="guc-ident-file"/>
configuration parameter.)
The ident map file contains lines of the general form:
<synopsis>
<para>
If the <replaceable>system-username</replaceable> field starts with a slash (<literal>/</literal>),
the remainder of the field is treated as a regular expression.
- (See <xref linkend="posix-syntax-details"> for details of
+ (See <xref linkend="posix-syntax-details"/> for details of
<productname>PostgreSQL</productname>'s regular expression syntax.) The regular
expression can include a single capture, or parenthesized subexpression,
which can then be referenced in the <replaceable>database-username</replaceable>
<para>
A <filename>pg_ident.conf</filename> file that could be used in
conjunction with the <filename>pg_hba.conf</filename> file in <xref
- linkend="example-pg-hba.conf"> is shown in <xref
- linkend="example-pg-ident.conf">. In this example, anyone
+ linkend="example-pg-hba.conf"/> is shown in <xref
+ linkend="example-pg-ident.conf"/>. In this example, anyone
logged in to a machine on the 192.168 network that does not have the
operating system user name <literal>bryanh</literal>, <literal>ann</literal>, or
<literal>robert</literal> would not be granted access. Unix user
Unix-domain socket file using file-system permissions. To do this, set the
<varname>unix_socket_permissions</varname> (and possibly
<varname>unix_socket_group</varname>) configuration parameters as
- described in <xref linkend="runtime-config-connection">. Or you
+ described in <xref linkend="runtime-config-connection"/>. Or you
could set the <varname>unix_socket_directories</varname>
configuration parameter to place the socket file in a suitably
restricted directory.
<para>
The <literal>md5</literal> method cannot be used with
- the <xref linkend="guc-db-user-namespace"> feature.
+ the <xref linkend="guc-db-user-namespace"/> feature.
</para>
<para>
separate from operating system user passwords. The password for
each database user is stored in the <literal>pg_authid</literal> system
catalog. Passwords can be managed with the SQL commands
- <xref linkend="sql-createrole"> and
- <xref linkend="sql-alterrole">,
+ <xref linkend="sql-createrole"/> and
+ <xref linkend="sql-alterrole"/>,
e.g., <userinput>CREATE ROLE foo WITH LOGIN PASSWORD 'secret'</userinput>,
or the <application>psql</application>
command <literal>\password</literal>.
The availability of the different password-based authentication methods
depends on how a user's password on the server is encrypted (or hashed,
more accurately). This is controlled by the configuration
- parameter <xref linkend="guc-password-encryption"> at the time the
+ parameter <xref linkend="guc-password-encryption"/> at the time the
password is set. If a password was encrypted using
the <literal>scram-sha-256</literal> setting, then it can be used for the
authentication methods <literal>scram-sha-256</literal>
<para>
GSSAPI support has to be enabled when <productname>PostgreSQL</productname> is built;
- see <xref linkend="installation"> for more information.
+ see <xref linkend="installation"/> for more information.
</para>
<para>
The PostgreSQL server will accept any principal that is included in the keytab used by
the server, but care needs to be taken to specify the correct principal details when
making the connection from the client using the <literal>krbsrvname</literal> connection parameter. (See
- also <xref linkend="libpq-paramkeywords">.) The installation default can be
+ also <xref linkend="libpq-paramkeywords"/>.) The installation default can be
changed from the default <literal>postgres</literal> at build time using
<literal>./configure --with-krb-srvnam=</literal><replaceable>whatever</replaceable>.
In most environments,
<para>
Make sure that your server keytab file is readable (and preferably
only readable, not writable) by the <productname>PostgreSQL</productname>
- server account. (See also <xref linkend="postgres-user">.) The location
+ server account. (See also <xref linkend="postgres-user"/>.) The location
of the key file is specified by the <xref
- linkend="guc-krb-server-keyfile"> configuration
+ linkend="guc-krb-server-keyfile"/> configuration
parameter. The default is
<filename>/usr/local/pgsql/etc/krb5.keytab</filename> (or whatever
directory was specified as <varname>sysconfdir</varname> at build time).
database user name <literal>fred</literal>, principal
<literal>fred@EXAMPLE.COM</literal> would be able to connect. To also allow
principal <literal>fred/users.example.com@EXAMPLE.COM</literal>, use a user name
- map, as described in <xref linkend="auth-username-maps">.
+ map, as described in <xref linkend="auth-username-maps"/>.
</para>
<para>
<para>
If set to 0, the realm name from the authenticated user principal is
stripped off before being passed through the user name mapping
- (<xref linkend="auth-username-maps">). This is discouraged and is
+ (<xref linkend="auth-username-maps"/>). This is discouraged and is
primarily available for backwards compatibility, as it is not secure
in multi-realm environments unless <literal>krb_realm</literal> is
also used. It is recommended to
<listitem>
<para>
Allows for mapping between system and database user names. See
- <xref linkend="auth-username-maps"> for details. For a GSSAPI/Kerberos
+ <xref linkend="auth-username-maps"/> for details. For a GSSAPI/Kerberos
principal, such as <literal>username@EXAMPLE.COM</literal> (or, less
commonly, <literal>username/hostbased@EXAMPLE.COM</literal>), the
user name used for mapping is
<para>
When using <productname>Kerberos</productname> authentication,
<productname>SSPI</productname> works the same way
- <productname>GSSAPI</productname> does; see <xref linkend="gssapi-auth">
+ <productname>GSSAPI</productname> does; see <xref linkend="gssapi-auth"/>
for details.
</para>
<para>
If set to 0, the realm name from the authenticated user principal is
stripped off before being passed through the user name mapping
- (<xref linkend="auth-username-maps">). This is discouraged and is
+ (<xref linkend="auth-username-maps"/>). This is discouraged and is
primarily available for backwards compatibility, as it is not secure
in multi-realm environments unless <literal>krb_realm</literal> is
also used. It is recommended to
<listitem>
<para>
Allows for mapping between system and database user names. See
- <xref linkend="auth-username-maps"> for details. For a SSPI/Kerberos
+ <xref linkend="auth-username-maps"/> for details. For a SSPI/Kerberos
principal, such as <literal>username@EXAMPLE.COM</literal> (or, less
commonly, <literal>username/hostbased@EXAMPLE.COM</literal>), the
user name used for mapping is
<note>
<para>
When ident is specified for a local (non-TCP/IP) connection,
- peer authentication (see <xref linkend="auth-peer">) will be
+ peer authentication (see <xref linkend="auth-peer"/>) will be
used instead.
</para>
</note>
<listitem>
<para>
Allows for mapping between system and database user names. See
- <xref linkend="auth-username-maps"> for details.
+ <xref linkend="auth-username-maps"/> for details.
</para>
</listitem>
</varlistentry>
<listitem>
<para>
Allows for mapping between system and database user names. See
- <xref linkend="auth-username-maps"> for details.
+ <xref linkend="auth-username-maps"/> for details.
</para>
</listitem>
</varlistentry>
<listitem>
<para>
Allows for mapping between system and database user names. See
- <xref linkend="auth-username-maps"> for details.
+ <xref linkend="auth-username-maps"/> for details.
</para>
</listitem>
</varlistentry>
<filename>postgresql.auto.conf</filename><indexterm><primary>postgresql.auto.conf</primary></indexterm>,
which has the same format as <filename>postgresql.conf</filename> but should
never be edited manually. This file holds settings provided through
- the <xref linkend="sql-altersystem"> command. This file is automatically
+ the <xref linkend="sql-altersystem"/> command. This file is automatically
read whenever <filename>postgresql.conf</filename> is, and its settings take
effect in the same way. Settings in <filename>postgresql.auto.conf</filename>
override those in <filename>postgresql.conf</filename>.
<para>
<productname>PostgreSQL</productname> provides three SQL
commands to establish configuration defaults.
- The already-mentioned <xref linkend="sql-altersystem"> command
+ The already-mentioned <xref linkend="sql-altersystem"/> command
provides a SQL-accessible means of changing global defaults; it is
functionally equivalent to editing <filename>postgresql.conf</filename>.
In addition, there are two commands that allow setting of defaults
<itemizedlist>
<listitem>
<para>
- The <xref linkend="sql-alterdatabase"> command allows global
+ The <xref linkend="sql-alterdatabase"/> command allows global
settings to be overridden on a per-database basis.
</para>
</listitem>
<listitem>
<para>
- The <xref linkend="sql-alterrole"> command allows both global and
+ The <xref linkend="sql-alterrole"/> command allows both global and
per-database settings to be overridden with user-specific values.
</para>
</listitem>
<itemizedlist>
<listitem>
<para>
- The <xref linkend="sql-show"> command allows inspection of the
+ The <xref linkend="sql-show"/> command allows inspection of the
current value of all parameters. The corresponding function is
<function>current_setting(setting_name text)</function>.
</para>
<listitem>
<para>
- The <xref linkend="sql-set"> command allows modification of the
+ The <xref linkend="sql-set"/> command allows modification of the
current value of those parameters that can be set locally to a
session; it has no effect on other sessions.
The corresponding function is
<listitem>
<para>
- Using <xref linkend="sql-update"> on this view, specifically
+ Using <xref linkend="sql-update"/> on this view, specifically
updating the <structname>setting</structname> column, is the equivalent
of issuing <command>SET</command> commands. For example, the equivalent of
<programlisting>
already mentioned, <productname>PostgreSQL</productname> uses
two other manually-edited configuration files, which control
client authentication (their use is discussed in <xref
- linkend="client-authentication">). By default, all three
+ linkend="client-authentication"/>). By default, all three
configuration files are stored in the database cluster's data
directory. The parameters described in this section allow the
configuration files to be placed elsewhere. (Doing so can ease
Specifies the configuration file for user name mapping
(customarily called <filename>pg_ident.conf</filename>).
This parameter can only be set at server start.
- See also <xref linkend="auth-username-maps">.
+ See also <xref linkend="auth-username-maps"/>.
</para>
</listitem>
</varlistentry>
The default value is <systemitem class="systemname">localhost</systemitem>,
which allows only local TCP/IP <quote>loopback</quote> connections to be
made. While client authentication (<xref
- linkend="client-authentication">) allows fine-grained control
+ linkend="client-authentication"/>) allows fine-grained control
over who can access the server, <varname>listen_addresses</varname>
controls which interfaces accept connection attempts, which
can help prevent repeated malicious connection requests on
<para>
Determines the number of connection <quote>slots</quote> that
are reserved for connections by <productname>PostgreSQL</productname>
- superusers. At most <xref linkend="guc-max-connections">
+ superusers. At most <xref linkend="guc-max-connections"/>
connections can ever be active simultaneously. Whenever the
number of active concurrent connections is at least
<varname>max_connections</varname> minus
<para>
This access control mechanism is independent of the one
- described in <xref linkend="client-authentication">.
+ described in <xref linkend="client-authentication"/>.
</para>
<para>
<listitem>
<para>
Enables <acronym>SSL</acronym> connections. Please read
- <xref linkend="ssl-tcp"> before using this.
+ <xref linkend="ssl-tcp"/> before using this.
This parameter can only be set in the <filename>postgresql.conf</filename>
file or on the server command line.
The default is <literal>off</literal>.
</term>
<listitem>
<para>
- When a password is specified in <xref linkend="sql-createrole"> or
- <xref linkend="sql-alterrole">, this parameter determines the algorithm
+ When a password is specified in <xref linkend="sql-createrole"/> or
+ <xref linkend="sql-alterrole"/>, this parameter determines the algorithm
to use to encrypt the password. The default value is <literal>md5</literal>,
which stores the password as an MD5 hash (<literal>on</literal> is also
accepted, as alias for <literal>md5</literal>). Setting this parameter to
<para>
Note that older clients might lack support for the SCRAM authentication
mechanism, and hence not work with passwords encrypted with
- SCRAM-SHA-256. See <xref linkend="auth-password"> for more details.
+ SCRAM-SHA-256. See <xref linkend="auth-password"/> for more details.
</para>
</listitem>
</varlistentry>
<listitem>
<para>
Sets the location of the Kerberos server key file. See
- <xref linkend="gssapi-auth">
+ <xref linkend="gssapi-auth"/>
for details. This parameter can only be set in the
<filename>postgresql.conf</filename> file or on the server command line.
</para>
<para>
The use of huge pages results in smaller page tables and less CPU time
spent on memory management, increasing performance. For more details,
- see <xref linkend="linux-huge-pages">.
+ see <xref linkend="linux-huge-pages"/>.
</para>
<para>
<para>
Sets the maximum number of transactions that can be in the
<quote>prepared</quote> state simultaneously (see <xref
- linkend="sql-prepare-transaction">).
+ linkend="sql-prepare-transaction"/>).
Setting this parameter to zero (which is the default)
disables the prepared-transaction feature.
This parameter can only be set at server start.
should be set to zero to prevent accidental creation of prepared
transactions. If you are using prepared transactions, you will
probably want <varname>max_prepared_transactions</varname> to be at
- least as large as <xref linkend="guc-max-connections">, so that every
+ least as large as <xref linkend="guc-max-connections"/>, so that every
session can have a prepared transaction pending.
</para>
</para>
<para>
Note that when autovacuum runs, up to
- <xref linkend="guc-autovacuum-max-workers"> times this memory
+ <xref linkend="guc-autovacuum-max-workers"/> times this memory
may be allocated, so be careful not to set the default value
too high. It may be useful to control for this by separately
- setting <xref linkend="guc-autovacuum-work-mem">.
+ setting <xref linkend="guc-autovacuum-work-mem"/>.
</para>
</listitem>
</varlistentry>
<para>
Specifies the maximum amount of memory to be used by each
autovacuum worker process. It defaults to -1, indicating that
- the value of <xref linkend="guc-maintenance-work-mem"> should
+ the value of <xref linkend="guc-maintenance-work-mem"/> should
be used instead. The setting has no effect on the behavior of
<command>VACUUM</command> when run in other contexts.
</para>
<title>Cost-based Vacuum Delay</title>
<para>
- During the execution of <xref linkend="sql-vacuum">
- and <xref linkend="sql-analyze">
+ During the execution of <xref linkend="sql-vacuum"/>
+ and <xref linkend="sql-analyze"/>
commands, the system maintains an
internal counter that keeps track of the estimated cost of the
various I/O operations that are performed. When the accumulated
the OS writes data back in larger batches in the background. Often
that will result in greatly reduced transaction latency, but there
also are some cases, especially with workloads that are bigger than
- <xref linkend="guc-shared-buffers">, but smaller than the OS's page
+ <xref linkend="guc-shared-buffers"/>, but smaller than the OS's page
cache, where performance might degrade. This setting may have no
effect on some platforms. The valid range is between
<literal>0</literal>, which disables forced writeback, and
The default is 1 on supported systems, otherwise 0. This value can
be overridden for tables in a particular tablespace by setting the
tablespace parameter of the same name (see
- <xref linkend="sql-altertablespace">).
+ <xref linkend="sql-altertablespace"/>).
</para>
</listitem>
</varlistentry>
<para>
When changing this value, consider also adjusting
- <xref linkend="guc-max-parallel-workers"> and
- <xref linkend="guc-max-parallel-workers-per-gather">.
+ <xref linkend="guc-max-parallel-workers"/> and
+ <xref linkend="guc-max-parallel-workers-per-gather"/>.
</para>
</listitem>
</varlistentry>
Sets the maximum number of workers that can be started by a single
<literal>Gather</literal> or <literal>Gather Merge</literal> node.
Parallel workers are taken from the pool of processes established by
- <xref linkend="guc-max-worker-processes">, limited by
- <xref linkend="guc-max-parallel-workers">. Note that the requested
+ <xref linkend="guc-max-worker-processes"/>, limited by
+ <xref linkend="guc-max-parallel-workers"/>. Note that the requested
number of workers may not actually be available at run time. If this
occurs, the plan will run with fewer workers than expected, which may
be inefficient. The default value is 2. Setting this value to 0
system as an additional user session. This should be taken into
account when choosing a value for this setting, as well as when
configuring other settings that control resource utilization, such
- as <xref linkend="guc-work-mem">. Resource limits such as
+ as <xref linkend="guc-work-mem"/>. Resource limits such as
<varname>work_mem</varname> are applied individually to each worker,
which means the total utilization may be much higher across all
processes than it would normally be for any single process.
<para>
For more information on parallel query, see
- <xref linkend="parallel-query">.
+ <xref linkend="parallel-query"/>.
</para>
</listitem>
</varlistentry>
Sets the maximum number of workers that the system can support for
parallel queries. The default value is 8. When increasing or
decreasing this value, consider also adjusting
- <xref linkend="guc-max-parallel-workers-per-gather">.
+ <xref linkend="guc-max-parallel-workers-per-gather"/>.
Also, note that a setting for this value which is higher than
- <xref linkend="guc-max-worker-processes"> will have no effect,
+ <xref linkend="guc-max-worker-processes"/> will have no effect,
since parallel workers are taken from the pool of worker processes
established by that setting.
</para>
checkpoint, or when the OS writes data back in larger batches in the
background. Often that will result in greatly reduced transaction
latency, but there also are some cases, especially with workloads
- that are bigger than <xref linkend="guc-shared-buffers">, but smaller
+ that are bigger than <xref linkend="guc-shared-buffers"/>, but smaller
than the OS's page cache, where performance might degrade. This
setting may have no effect on some platforms. The valid range is
between <literal>0</literal>, which disables forced writeback,
<para>
For additional information on tuning these settings,
- see <xref linkend="wal-configuration">.
+ see <xref linkend="wal-configuration"/>.
</para>
<sect2 id="runtime-config-wal-settings">
<para>
In <literal>minimal</literal> level, WAL-logging of some bulk
operations can be safely skipped, which can make those
- operations much faster (see <xref linkend="populate-pitr">).
+ operations much faster (see <xref linkend="populate-pitr"/>).
Operations in which this optimization can be applied include:
<simplelist>
<member><command>CREATE TABLE AS</command></member>
But minimal WAL does not contain enough information to reconstruct the
data from a base backup and the WAL logs, so <literal>replica</literal> or
higher must be used to enable WAL archiving
- (<xref linkend="guc-archive-mode">) and streaming replication.
+ (<xref linkend="guc-archive-mode"/>) and streaming replication.
</para>
<para>
In <literal>logical</literal> level, the same information is logged as
If this parameter is on, the <productname>PostgreSQL</productname> server
will try to make sure that updates are physically written to
disk, by issuing <function>fsync()</function> system calls or various
- equivalent methods (see <xref linkend="guc-wal-sync-method">).
+ equivalent methods (see <xref linkend="guc-wal-sync-method"/>).
This ensures that the database cluster can recover to a
consistent state after an operating system or hardware crash.
</para>
</para>
<para>
- In many situations, turning off <xref linkend="guc-synchronous-commit">
+ In many situations, turning off <xref linkend="guc-synchronous-commit"/>
for noncritical transactions can provide much of the potential
performance benefit of turning off <varname>fsync</varname>, without
the attendant risks of data corruption.
<varname>fsync</varname> can only be set in the <filename>postgresql.conf</filename>
file or on the server command line.
If you turn this parameter off, also consider turning off
- <xref linkend="guc-full-page-writes">.
+ <xref linkend="guc-full-page-writes"/>.
</para>
</listitem>
</varlistentry>
is <literal>on</literal>. When <literal>off</literal>, there can be a delay between
when success is reported to the client and when the transaction is
really guaranteed to be safe against a server crash. (The maximum
- delay is three times <xref linkend="guc-wal-writer-delay">.) Unlike
- <xref linkend="guc-fsync">, setting this parameter to <literal>off</literal>
+ delay is three times <xref linkend="guc-wal-writer-delay"/>.) Unlike
+ <xref linkend="guc-fsync"/>, setting this parameter to <literal>off</literal>
does not create any risk of database inconsistency: an operating
system or database crash might
result in some recent allegedly-committed transactions being lost, but
been aborted cleanly. So, turning <varname>synchronous_commit</varname> off
can be a useful alternative when performance is more important than
exact certainty about the durability of a transaction. For more
- discussion see <xref linkend="wal-async-commit">.
+ discussion see <xref linkend="wal-async-commit"/>.
</para>
<para>
- If <xref linkend="guc-synchronous-standby-names"> is non-empty, this
+ If <xref linkend="guc-synchronous-standby-names"/> is non-empty, this
parameter also controls whether or not transaction commits will wait
for their WAL records to be replicated to the standby server(s).
When set to <literal>on</literal>, commits will wait until replies
necessary to change this setting or other aspects of your system
configuration in order to create a crash-safe configuration or
achieve optimal performance.
- These aspects are discussed in <xref linkend="wal-reliability">.
+ These aspects are discussed in <xref linkend="wal-reliability"/>.
This parameter can only be set in the <filename>postgresql.conf</filename>
file or on the server command line.
</para>
<para>
Turning off this parameter does not affect use of
WAL archiving for point-in-time recovery (PITR)
- (see <xref linkend="continuous-archiving">).
+ (see <xref linkend="continuous-archiving"/>).
</para>
<para>
<para>
When this parameter is <literal>on</literal>, the <productname>PostgreSQL</productname>
server compresses a full page image written to WAL when
- <xref linkend="guc-full-page-writes"> is on or during a base backup.
+ <xref linkend="guc-full-page-writes"/> is on or during a base backup.
A compressed page image will be decompressed during WAL replay.
The default value is <literal>off</literal>.
Only superusers can change this setting.
<para>
The amount of shared memory used for WAL data that has not yet been
written to disk. The default setting of -1 selects a size equal to
- 1/32nd (about 3%) of <xref linkend="guc-shared-buffers">, but not less
+ 1/32nd (about 3%) of <xref linkend="guc-shared-buffers"/>, but not less
than <literal>64kB</literal> nor more than the size of one WAL
segment, typically <literal>16MB</literal>. This value can be set
manually if the automatic choice is too large or too small,
checkpoint, or when the OS writes data back in larger batches in the
background. Often that will result in greatly reduced transaction
latency, but there also are some cases, especially with workloads
- that are bigger than <xref linkend="guc-shared-buffers">, but smaller
+ that are bigger than <xref linkend="guc-shared-buffers"/>, but smaller
than the OS's page cache, where performance might degrade. This
setting may have no effect on some platforms. The valid range is
between <literal>0</literal>, which disables forced writeback,
<para>
When <varname>archive_mode</varname> is enabled, completed WAL segments
are sent to archive storage by setting
- <xref linkend="guc-archive-command">. In addition to <literal>off</literal>,
+ <xref linkend="guc-archive-command"/>. In addition to <literal>off</literal>,
to disable, there are two modes: <literal>on</literal>, and
<literal>always</literal>. During normal operation, there is no
difference between the two modes, but when set to <literal>always</literal>
the WAL archiver is enabled also during archive recovery or standby
mode. In <literal>always</literal> mode, all files restored from the archive
or streamed with streaming replication will be archived (again). See
- <xref linkend="continuous-archiving-in-standby"> for details.
+ <xref linkend="continuous-archiving-in-standby"/> for details.
</para>
<para>
<varname>archive_mode</varname> and <varname>archive_command</varname> are
Use <literal>%%</literal> to embed an actual <literal>%</literal> character in the
command. It is important for the command to return a zero
exit status only if it succeeds. For more information see
- <xref linkend="backup-archiving-wal">.
+ <xref linkend="backup-archiving-wal"/>.
</para>
<para>
This parameter can only be set in the <filename>postgresql.conf</filename>
</term>
<listitem>
<para>
- The <xref linkend="guc-archive-command"> is only invoked for
+ The <xref linkend="guc-archive-command"/> is only invoked for
completed WAL segments. Hence, if your server generates little WAL
traffic (or has slack periods where it does so), there could be a
long delay between the completion of a transaction and its safe
<para>
These settings control the behavior of the built-in
<firstterm>streaming replication</firstterm> feature (see
- <xref linkend="streaming-replication">). Servers will be either a
+ <xref linkend="streaming-replication"/>). Servers will be either a
Master or a Standby server. Masters can send data, while Standby(s)
are always receivers of replicated data. When cascading replication
- (see <xref linkend="cascading-replication">) is used, Standby server(s)
+ (see <xref linkend="cascading-replication"/>) is used, Standby server(s)
can also be senders, as well as receivers.
Parameters are mainly for Sending and Standby servers, though some
parameters have meaning only on the Master server. Settings may vary
processes). The default is 10. The value 0 means replication is
disabled. WAL sender processes count towards the total number
of connections, so the parameter cannot be set higher than
- <xref linkend="guc-max-connections">. Abrupt streaming client
+ <xref linkend="guc-max-connections"/>. Abrupt streaming client
disconnection might cause an orphaned connection slot until
a timeout is reached, so this parameter should be set slightly
higher than the maximum number of expected clients so disconnected
<listitem>
<para>
Specifies the maximum number of replication slots
- (see <xref linkend="streaming-replication-slots">) that the server
+ (see <xref linkend="streaming-replication-slots"/>) that the server
can support. The default is 10. This parameter can only be set at
server start.
<varname>wal_level</varname> must be set
These parameters can be set on the master/primary server that is
to send replication data to one or more standby servers.
Note that in addition to these parameters,
- <xref linkend="guc-wal-level"> must be set appropriately on the master
+ <xref linkend="guc-wal-level"/> must be set appropriately on the master
server, and optionally WAL archiving can be enabled as
- well (see <xref linkend="runtime-config-wal-archiving">).
+ well (see <xref linkend="runtime-config-wal-archiving"/>).
The values of these parameters on standby servers are irrelevant,
although you may wish to set them there in preparation for the
possibility of a standby becoming the master.
<para>
Specifies a list of standby servers that can support
<firstterm>synchronous replication</firstterm>, as described in
- <xref linkend="synchronous-replication">.
+ <xref linkend="synchronous-replication"/>.
There will be one or more active synchronous standbys;
transactions waiting for commit will be allowed to proceed after
these standby servers confirm receipt of their data.
replication. This is the default configuration. Even when
synchronous replication is enabled, individual transactions can be
configured not to wait for replication by setting the
- <xref linkend="guc-synchronous-commit"> parameter to
+ <xref linkend="guc-synchronous-commit"/> parameter to
<literal>local</literal> or <literal>off</literal>.
</para>
<para>
removed as soon as possible, that is, as soon as they are no longer
visible to any open transaction. You may wish to set this to a
non-zero value on a primary server that is supporting hot standby
- servers, as described in <xref linkend="hot-standby">. This allows
+ servers, as described in <xref linkend="hot-standby"/>. This allows
more time for queries on the standby to complete without incurring
conflicts due to early cleanup of rows. However, since the value
is measured in terms of number of write transactions occurring on the
<listitem>
<para>
Specifies whether or not you can connect and run queries during
- recovery, as described in <xref linkend="hot-standby">.
+ recovery, as described in <xref linkend="hot-standby"/>.
The default value is <literal>on</literal>.
This parameter can only be set at server start. It only has effect
during archive recovery or in standby mode.
When Hot Standby is active, this parameter determines how long the
standby server should wait before canceling standby queries that
conflict with about-to-be-applied WAL entries, as described in
- <xref linkend="hot-standby-conflict">.
+ <xref linkend="hot-standby-conflict"/>.
<varname>max_standby_archive_delay</varname> applies when WAL data is
being read from WAL archive (and is therefore not current).
The default is 30 seconds. Units are milliseconds if not specified.
When Hot Standby is active, this parameter determines how long the
standby server should wait before canceling standby queries that
conflict with about-to-be-applied WAL entries, as described in
- <xref linkend="hot-standby-conflict">.
+ <xref linkend="hot-standby-conflict"/>.
<varname>max_standby_streaming_delay</varname> applies when WAL data is
being received via streaming replication.
The default is 30 seconds. Units are milliseconds if not specified.
choose a different plan.
Better ways to improve the quality of the
plans chosen by the optimizer include adjusting the planner cost
- constants (see <xref linkend="runtime-config-query-constants">),
- running <xref linkend="sql-analyze"> manually, increasing
+ constants (see <xref linkend="runtime-config-query-constants"/>),
+ running <xref linkend="sql-analyze"/> manually, increasing
the value of the <xref
- linkend="guc-default-statistics-target"> configuration parameter,
+ linkend="guc-default-statistics-target"/> configuration parameter,
and increasing the amount of statistics collected for
specific columns using <command>ALTER TABLE SET
STATISTICS</command>.
<listitem>
<para>
Enables or disables the query planner's use of index-only-scan plan
- types (see <xref linkend="indexes-index-only-scans">).
+ types (see <xref linkend="indexes-index-only-scans"/>).
The default is <literal>on</literal>.
</para>
</listitem>
that is part of a series of sequential fetches. The default is 1.0.
This value can be overridden for tables and indexes in a particular
tablespace by setting the tablespace parameter of the same name
- (see <xref linkend="sql-altertablespace">).
+ (see <xref linkend="sql-altertablespace"/>).
</para>
</listitem>
</varlistentry>
non-sequentially-fetched disk page. The default is 4.0.
This value can be overridden for tables and indexes in a particular
tablespace by setting the tablespace parameter of the same name
- (see <xref linkend="sql-altertablespace">).
+ (see <xref linkend="sql-altertablespace"/>).
</para>
<para>
complex queries (those joining many relations), at the cost of producing
plans that are sometimes inferior to those found by the normal
exhaustive-search algorithm.
- For more information see <xref linkend="geqo">.
+ For more information see <xref linkend="geqo"/>.
</para>
<variablelist>
do <command>ANALYZE</command>, but might improve the quality of the
planner's estimates. The default is 100. For more information
on the use of statistics by the <productname>PostgreSQL</productname>
- query planner, refer to <xref linkend="planner-stats">.
+ query planner, refer to <xref linkend="planner-stats"/>.
</para>
</listitem>
</varlistentry>
</para>
<para>
- Refer to <xref linkend="ddl-partitioning-constraint-exclusion"> for
+ Refer to <xref linkend="ddl-partitioning-constraint-exclusion"/> for
more information on using constraint exclusion and partitioning.
</para>
</listitem>
resulting <literal>FROM</literal> list would have no more than
this many items. Smaller values reduce planning time but might
yield inferior query plans. The default is eight.
- For more information see <xref linkend="explicit-joins">.
+ For more information see <xref linkend="explicit-joins"/>.
</para>
<para>
- Setting this value to <xref linkend="guc-geqo-threshold"> or more
+ Setting this value to <xref linkend="guc-geqo-threshold"/> or more
may trigger use of the GEQO planner, resulting in non-optimal
- plans. See <xref linkend="runtime-config-query-geqo">.
+ plans. See <xref linkend="runtime-config-query-geqo"/>.
</para>
</listitem>
</varlistentry>
the optimal join order, advanced users can elect to
temporarily set this variable to 1, and then specify the join
order they desire explicitly.
- For more information see <xref linkend="explicit-joins">.
+ For more information see <xref linkend="explicit-joins"/>.
</para>
<para>
- Setting this value to <xref linkend="guc-geqo-threshold"> or more
+ Setting this value to <xref linkend="guc-geqo-threshold"/> or more
may trigger use of the GEQO planner, resulting in non-optimal
- plans. See <xref linkend="runtime-config-query-geqo">.
+ plans. See <xref linkend="runtime-config-query-geqo"/>.
</para>
</listitem>
</varlistentry>
log entries are output in <quote>comma separated
value</quote> (<acronym>CSV</acronym>) format, which is convenient for
loading logs into programs.
- See <xref linkend="runtime-config-logging-csvlog"> for details.
- <xref linkend="guc-logging-collector"> must be enabled to generate
+ See <xref linkend="runtime-config-logging-csvlog"/> for details.
+ <xref linkend="guc-logging-collector"/> must be enabled to generate
CSV-format log output.
</para>
<para>
<varname>log_destination</varname>. <productname>PostgreSQL</productname>
can log to <application>syslog</application> facilities
<literal>LOCAL0</literal> through <literal>LOCAL7</literal> (see <xref
- linkend="guc-syslog-facility">), but the default
+ linkend="guc-syslog-facility"/>), but the default
<application>syslog</application> configuration on most platforms
will discard all such messages. You will need to add something like:
<programlisting>
register an event source and its library with the operating
system so that the Windows Event Viewer can display event
log messages cleanly.
- See <xref linkend="event-log-registration"> for details.
+ See <xref linkend="event-log-registration"/> for details.
</para>
</note>
</listitem>
file names. (Note that if there are
any time-zone-dependent <literal>%</literal>-escapes, the computation
is done in the zone specified
- by <xref linkend="guc-log-timezone">.)
+ by <xref linkend="guc-log-timezone"/>.)
The supported <literal>%</literal>-escapes are similar to those
listed in the Open Group's <ulink
url="http://pubs.opengroup.org/onlinepubs/009695399/functions/strftime.html">strftime
server owner can read or write the log files. The other commonly
useful setting is <literal>0640</literal>, allowing members of the owner's
group to read the files. Note however that to make use of such a
- setting, you'll need to alter <xref linkend="guc-log-directory"> to
+ setting, you'll need to alter <xref linkend="guc-log-directory"/> to
store the files somewhere outside the cluster data directory. In
any case, it's unwise to make the log files world-readable, since
they might contain sensitive data.
<note>
<para>
When using this option together with
- <xref linkend="guc-log-statement">,
+ <xref linkend="guc-log-statement"/>,
the text of statements that are logged because of
<varname>log_statement</varname> will not be repeated in the
duration log message.
If you are not using <application>syslog</application>, it is recommended
that you log the PID or session ID using
- <xref linkend="guc-log-line-prefix">
+ <xref linkend="guc-log-line-prefix"/>
so that you can link the statement message to the later
duration message using the process ID or session ID.
</para>
</variablelist>
<para>
- <xref linkend="runtime-config-severity-levels"> explains the message
+ <xref linkend="runtime-config-severity-levels"/> explains the message
severity levels used by <productname>PostgreSQL</productname>. If logging output
is sent to <systemitem>syslog</systemitem> or Windows'
<systemitem>eventlog</systemitem>, the severity levels are translated
It is typically set by an application upon connection to the server.
The name will be displayed in the <structname>pg_stat_activity</structname> view
and included in CSV log entries. It can also be included in regular
- log entries via the <xref linkend="guc-log-line-prefix"> parameter.
+ log entries via the <xref linkend="guc-log-line-prefix"/> parameter.
Only printable ASCII characters may be used in the
<varname>application_name</varname> value. Other characters will be
replaced with question marks (<literal>?</literal>).
These messages are emitted at <literal>LOG</literal> message level, so by
default they will appear in the server log but will not be sent to the
client. You can change that by adjusting
- <xref linkend="guc-client-min-messages"> and/or
- <xref linkend="guc-log-min-messages">.
+ <xref linkend="guc-client-min-messages"/> and/or
+ <xref linkend="guc-log-min-messages"/>.
These parameters are off by default.
</para>
</listitem>
<note>
<para>
The difference between setting this option and setting
- <xref linkend="guc-log-min-duration-statement"> to zero is that
+ <xref linkend="guc-log-min-duration-statement"/> to zero is that
exceeding <varname>log_min_duration_statement</varname> forces the text of
the query to be logged, but this option doesn't. Thus, if
<varname>log_duration</varname> is <literal>on</literal> and
the logging of <literal>DETAIL</literal>, <literal>HINT</literal>,
<literal>QUERY</literal>, and <literal>CONTEXT</literal> error information.
<literal>VERBOSE</literal> output includes the <symbol>SQLSTATE</symbol> error
- code (see also <xref linkend="errcodes-appendix">) and the source code file name, function name,
+ code (see also <xref linkend="errcodes-appendix"/>) and the source code file name, function name,
and line number that generated the error.
Only superusers can change this setting.
</para>
<listitem>
<para>
Controls whether a log message is produced when a session waits
- longer than <xref linkend="guc-deadlock-timeout"> to acquire a
+ longer than <xref linkend="guc-deadlock-timeout"/> to acquire a
lock. This is useful in determining if lock waits are causing
poor performance. The default is <literal>off</literal>.
Only superusers can change this setting.
<listitem>
<para>
Causes each replication command to be logged in the server log.
- See <xref linkend="protocol-replication"> for more information about
+ See <xref linkend="protocol-replication"/> for more information about
replication command. The default value is <literal>off</literal>.
Only superusers can change this setting.
</para>
<listitem>
<para>
Sets the time zone used for timestamps written in the server log.
- Unlike <xref linkend="guc-timezone">, this value is cluster-wide,
+ Unlike <xref linkend="guc-timezone"/>, this value is cluster-wide,
so that all sessions will report timestamps consistently.
The built-in default is <literal>GMT</literal>, but that is typically
overridden in <filename>postgresql.conf</filename>; <application>initdb</application>
will install a setting there corresponding to its system environment.
- See <xref linkend="datatype-timezones"> for more information.
+ See <xref linkend="datatype-timezones"/> for more information.
This parameter can only be set in the <filename>postgresql.conf</filename>
file or on the server command line.
</para>
These settings control how process titles of server processes are
modified. Process titles are typically viewed using programs like
<application>ps</application> or, on Windows, <application>Process Explorer</application>.
- See <xref linkend="monitoring-ps"> for details.
+ See <xref linkend="monitoring-ps"/> for details.
</para>
<variablelist>
When statistics collection is enabled, the data that is produced can be
accessed via the <structname>pg_stat</structname> and
<structname>pg_statio</structname> family of system views.
- Refer to <xref linkend="monitoring"> for more information.
+ Refer to <xref linkend="monitoring"/> for more information.
</para>
<variablelist>
Enables timing of database I/O calls. This parameter is off by
default, because it will repeatedly query the operating system for
the current time, which may cause significant overhead on some
- platforms. You can use the <xref linkend="pgtesttiming"> tool to
+ platforms. You can use the <xref linkend="pgtesttiming"/> tool to
measure the overhead of timing on your system.
I/O timing information is
- displayed in <xref linkend="pg-stat-database-view">, in the output of
- <xref linkend="sql-explain"> when the <literal>BUFFERS</literal> option is
- used, and by <xref linkend="pgstatstatements">. Only superusers can
+ displayed in <xref linkend="pg-stat-database-view"/>, in the output of
+ <xref linkend="sql-explain"/> when the <literal>BUFFERS</literal> option is
+ used, and by <xref linkend="pgstatstatements"/>. Only superusers can
change this setting.
</para>
</listitem>
<para>
These settings control the behavior of the <firstterm>autovacuum</firstterm>
- feature. Refer to <xref linkend="autovacuum"> for more information.
+ feature. Refer to <xref linkend="autovacuum"/> for more information.
Note that many of these settings can be overridden on a per-table
basis; see <xref linkend="sql-createtable-storage-parameters"
- endterm="sql-createtable-storage-parameters-title">.
+ endterm="sql-createtable-storage-parameters-title"/>.
</para>
<variablelist>
<para>
Controls whether the server should run the
autovacuum launcher daemon. This is on by default; however,
- <xref linkend="guc-track-counts"> must also be enabled for
+ <xref linkend="guc-track-counts"/> must also be enabled for
autovacuum to work.
This parameter can only be set in the <filename>postgresql.conf</filename>
file or on the server command line; however, autovacuuming can be
Note that even when this parameter is disabled, the system
will launch autovacuum processes if necessary to
prevent transaction ID wraparound. See <xref
- linkend="vacuum-for-wraparound"> for more information.
+ linkend="vacuum-for-wraparound"/> for more information.
</para>
</listitem>
</varlistentry>
This parameter can only be set at server start, but the setting
can be reduced for individual tables by
changing table storage parameters.
- For more information see <xref linkend="vacuum-for-wraparound">.
+ For more information see <xref linkend="vacuum-for-wraparound"/>.
</para>
</listitem>
</varlistentry>
400 million multixacts.
This parameter can only be set at server start, but the setting can
be reduced for individual tables by changing table storage parameters.
- For more information see <xref linkend="vacuum-for-multixact-wraparound">.
+ For more information see <xref linkend="vacuum-for-multixact-wraparound"/>.
</para>
</listitem>
</varlistentry>
<para>
Specifies the cost delay value that will be used in automatic
<command>VACUUM</command> operations. If -1 is specified, the regular
- <xref linkend="guc-vacuum-cost-delay"> value will be used.
+ <xref linkend="guc-vacuum-cost-delay"/> value will be used.
The default value is 20 milliseconds.
This parameter can only be set in the <filename>postgresql.conf</filename>
file or on the server command line;
Specifies the cost limit value that will be used in automatic
<command>VACUUM</command> operations. If -1 is specified (which is the
default), the regular
- <xref linkend="guc-vacuum-cost-limit"> value will be used. Note that
+ <xref linkend="guc-vacuum-cost-limit"/> value will be used. Note that
the value is distributed proportionally among the running autovacuum
workers, if there is more than one, so that the sum of the limits for
each worker does not exceed the value of this variable.
The current effective value of the search path can be examined
via the <acronym>SQL</acronym> function
<function>current_schemas</function>
- (see <xref linkend="functions-info">).
+ (see <xref linkend="functions-info"/>).
This is not quite the same as
examining the value of <varname>search_path</varname>, since
<function>current_schemas</function> shows how the items
</para>
<para>
- For more information on schema handling, see <xref linkend="ddl-schemas">.
+ For more information on schema handling, see <xref linkend="ddl-schemas"/>.
</para>
</listitem>
</varlistentry>
<para>
For more information on row security policies,
- see <xref linkend="sql-createpolicy">.
+ see <xref linkend="sql-createpolicy"/>.
</para>
</listitem>
</varlistentry>
<para>
This variable is not used for temporary tables; for them,
- <xref linkend="guc-temp-tablespaces"> is consulted instead.
+ <xref linkend="guc-temp-tablespaces"/> is consulted instead.
</para>
<para>
<para>
For more information on tablespaces,
- see <xref linkend="manage-ag-tablespaces">.
+ see <xref linkend="manage-ag-tablespaces"/>.
</para>
</listitem>
</varlistentry>
</para>
<para>
- See also <xref linkend="guc-default-tablespace">.
+ See also <xref linkend="guc-default-tablespace"/>.
</para>
</listitem>
</varlistentry>
<para>
This parameter is normally on. When set to <literal>off</literal>, it
disables validation of the function body string during <xref
- linkend="sql-createfunction">. Disabling validation avoids side
+ linkend="sql-createfunction"/>. Disabling validation avoids side
effects of the validation process and avoids false positives due
to problems such as forward references. Set this parameter
to <literal>off</literal> before loading functions on behalf of other
</para>
<para>
- Consult <xref linkend="mvcc"> and <xref
- linkend="sql-set-transaction"> for more information.
+ Consult <xref linkend="mvcc"/> and <xref
+ linkend="sql-set-transaction"/> for more information.
</para>
</listitem>
</varlistentry>
</para>
<para>
- Consult <xref linkend="sql-set-transaction"> for more information.
+ Consult <xref linkend="sql-set-transaction"/> for more information.
</para>
</listitem>
</varlistentry>
</para>
<para>
- Consult <xref linkend="sql-set-transaction"> for more information.
+ Consult <xref linkend="sql-set-transaction"/> for more information.
</para>
</listitem>
</varlistentry>
superuser privilege and results in discarding any previously cached
query plans. Possible values are <literal>origin</literal> (the default),
<literal>replica</literal> and <literal>local</literal>.
- See <xref linkend="sql-altertable"> for
+ See <xref linkend="sql-altertable"/> for
more information.
</para>
</listitem>
longer than the specified duration in milliseconds. This allows any
locks held by that session to be released and the connection slot to be reused;
it also allows tuples visible only to this transaction to be vacuumed. See
- <xref linkend="routine-vacuuming"> for more details about this.
+ <xref linkend="routine-vacuuming"/> for more details about this.
</para>
<para>
The default value of 0 disables this feature.
tuples. The default is 150 million transactions. Although users can
set this value anywhere from zero to two billions, <command>VACUUM</command>
will silently limit the effective value to 95% of
- <xref linkend="guc-autovacuum-freeze-max-age">, so that a
+ <xref linkend="guc-autovacuum-freeze-max-age"/>, so that a
periodical manual <command>VACUUM</command> has a chance to run before an
anti-wraparound autovacuum is launched for the table. For more
information see
- <xref linkend="vacuum-for-wraparound">.
+ <xref linkend="vacuum-for-wraparound"/>.
</para>
</listitem>
</varlistentry>
The default is 50 million transactions. Although
users can set this value anywhere from zero to one billion,
<command>VACUUM</command> will silently limit the effective value to half
- the value of <xref linkend="guc-autovacuum-freeze-max-age">, so
+ the value of <xref linkend="guc-autovacuum-freeze-max-age"/>, so
that there is not an unreasonably short time between forced
autovacuums. For more information see <xref
- linkend="vacuum-for-wraparound">.
+ linkend="vacuum-for-wraparound"/>.
</para>
</listitem>
</varlistentry>
tuples. The default is 150 million multixacts.
Although users can set this value anywhere from zero to two billions,
<command>VACUUM</command> will silently limit the effective value to 95% of
- <xref linkend="guc-autovacuum-multixact-freeze-max-age">, so that a
+ <xref linkend="guc-autovacuum-multixact-freeze-max-age"/>, so that a
periodical manual <command>VACUUM</command> has a chance to run before an
anti-wraparound is launched for the table.
- For more information see <xref linkend="vacuum-for-multixact-wraparound">.
+ For more information see <xref linkend="vacuum-for-multixact-wraparound"/>.
</para>
</listitem>
</varlistentry>
is 5 million multixacts.
Although users can set this value anywhere from zero to one billion,
<command>VACUUM</command> will silently limit the effective value to half
- the value of <xref linkend="guc-autovacuum-multixact-freeze-max-age">,
+ the value of <xref linkend="guc-autovacuum-multixact-freeze-max-age"/>,
so that there is not an unreasonably short time between forced
autovacuums.
- For more information see <xref linkend="vacuum-for-multixact-wraparound">.
+ For more information see <xref linkend="vacuum-for-multixact-wraparound"/>.
</para>
</listitem>
</varlistentry>
Sets the output format for values of type <type>bytea</type>.
Valid values are <literal>hex</literal> (the default)
and <literal>escape</literal> (the traditional PostgreSQL
- format). See <xref linkend="datatype-binary"> for more
+ format). See <xref linkend="datatype-binary"/> for more
information. The <type>bytea</type> type always
accepts both formats on input, regardless of this setting.
</para>
<literal>base64</literal> and <literal>hex</literal>, which
are both defined in the XML Schema standard. The default is
<literal>base64</literal>. For further information about
- XML-related functions, see <xref linkend="functions-xml">.
+ XML-related functions, see <xref linkend="functions-xml"/>.
</para>
<para>
Sets whether <literal>DOCUMENT</literal> or
<literal>CONTENT</literal> is implicit when converting between
XML and character string values. See <xref
- linkend="datatype-xml"> for a description of this. Valid
+ linkend="datatype-xml"/> for a description of this. Valid
values are <literal>DOCUMENT</literal> and
<literal>CONTENT</literal>. The default is
<literal>CONTENT</literal>.
The default is four megabytes (<literal>4MB</literal>). This setting
can be overridden for individual GIN indexes by changing
index storage parameters.
- See <xref linkend="gin-fast-update"> and <xref linkend="gin-tips">
+ See <xref linkend="gin-fast-update"/> and <xref linkend="gin-tips"/>
for more information.
</para>
</listitem>
and <literal>European</literal> are synonyms for <literal>DMY</literal>; the
keywords <literal>US</literal>, <literal>NonEuro</literal>, and
<literal>NonEuropean</literal> are synonyms for <literal>MDY</literal>. See
- <xref linkend="datatype-datetime"> for more information. The
+ <xref linkend="datatype-datetime"/> for more information. The
built-in default is <literal>ISO, MDY</literal>, but
<application>initdb</application> will initialize the
configuration file with a setting that corresponds to the
output matching <acronym>SQL</acronym> standard interval literals.
The value <literal>postgres</literal> (which is the default) will produce
output matching <productname>PostgreSQL</productname> releases prior to 8.4
- when the <xref linkend="guc-datestyle">
+ when the <xref linkend="guc-datestyle"/>
parameter was set to <literal>ISO</literal>.
The value <literal>postgres_verbose</literal> will produce output
matching <productname>PostgreSQL</productname> releases prior to 8.4
<para>
The <varname>IntervalStyle</varname> parameter also affects the
interpretation of ambiguous interval input. See
- <xref linkend="datatype-interval-input"> for more information.
+ <xref linkend="datatype-interval-input"/> for more information.
</para>
</listitem>
</varlistentry>
The built-in default is <literal>GMT</literal>, but that is typically
overridden in <filename>postgresql.conf</filename>; <application>initdb</application>
will install a setting there corresponding to its system environment.
- See <xref linkend="datatype-timezones"> for more information.
+ See <xref linkend="datatype-timezones"/> for more information.
</para>
</listitem>
</varlistentry>
which is a collection that works in most of the world; there are
also <literal>'Australia'</literal> and <literal>'India'</literal>,
and other collections can be defined for a particular installation.
- See <xref linkend="datetime-config-files"> for more information.
+ See <xref linkend="datetime-config-files"/> for more information.
</para>
</listitem>
</varlistentry>
partially-significant digits; this is especially useful for dumping
float data that needs to be restored exactly. Or it can be set
negative to suppress unwanted digits.
- See also <xref linkend="datatype-float">.
+ See also <xref linkend="datatype-float"/>.
</para>
</listitem>
</varlistentry>
Sets the client-side encoding (character set).
The default is to use the database encoding.
The character sets supported by the <productname>PostgreSQL</productname>
- server are described in <xref linkend="multibyte-charset-supported">.
+ server are described in <xref linkend="multibyte-charset-supported"/>.
</para>
</listitem>
</varlistentry>
<listitem>
<para>
Sets the language in which messages are displayed. Acceptable
- values are system-dependent; see <xref linkend="locale"> for
+ values are system-dependent; see <xref linkend="locale"/> for
more information. If this variable is set to the empty string
(which is the default) then the value is inherited from the
execution environment of the server in a system-dependent way.
Sets the locale to use for formatting monetary amounts, for
example with the <function>to_char</function> family of
functions. Acceptable values are system-dependent; see <xref
- linkend="locale"> for more information. If this variable is
+ linkend="locale"/> for more information. If this variable is
set to the empty string (which is the default) then the value
is inherited from the execution environment of the server in a
system-dependent way.
Sets the locale to use for formatting numbers, for example
with the <function>to_char</function> family of
functions. Acceptable values are system-dependent; see <xref
- linkend="locale"> for more information. If this variable is
+ linkend="locale"/> for more information. If this variable is
set to the empty string (which is the default) then the value
is inherited from the execution environment of the server in a
system-dependent way.
Sets the locale to use for formatting dates and times, for example
with the <function>to_char</function> family of
functions. Acceptable values are system-dependent; see <xref
- linkend="locale"> for more information. If this variable is
+ linkend="locale"/> for more information. If this variable is
set to the empty string (which is the default) then the value
is inherited from the execution environment of the server in a
system-dependent way.
Selects the text search configuration that is used by those variants
of the text search functions that do not have an explicit argument
specifying the configuration.
- See <xref linkend="textsearch"> for further information.
+ See <xref linkend="textsearch"/> for further information.
The built-in default is <literal>pg_catalog.simple</literal>, but
<application>initdb</application> will initialize the
configuration file with a setting that corresponds to the
projects / users / rhaas / postgres.git / commitdiff