Additional Supplied Modules
- This appendix contains information regarding the modules that
+ This appendix and the next one contain information regarding the modules that
can be found in the contrib directory of the
PostgreSQL> distribution.
These include porting tools, analysis utilities,
@@ -15,7 +15,13 @@
- When building from the source distribution, these modules are not built
+ This appendix covers extensions and other server plug-in modules found in
+ contrib. covers utility
+ programs.
+
+
+
+ When building from the source distribution, these components are not built
automatically, unless you build the "world" target
(see ).
You can build and install all of them by running:
@@ -88,6 +94,14 @@ CREATE EXTENSION module_name> FROM unpackaged;
.
+
+ Note, however, that some of these modules are not extensions
+ in this sense, but are loaded into the server in some other way, for instance
+ by way of
+ . See the documentation of each
+ module for details.
+
+
&adminpack;
&auth-delay;
&auto-explain;
@@ -109,22 +123,15 @@ CREATE EXTENSION module_name> FROM unpackaged;
&isn;
&lo;
<ree;
- &oid2name;
&pageinspect;
&passwordcheck;
- &pgarchivecleanup;
- &pgbench;
&pgbuffercache;
&pgcrypto;
&pgfreespacemap;
&pgrowlocks;
- &pgstandby;
&pgstatstatements;
&pgstattuple;
- &pgtestfsync;
- &pgtesttiming;
&pgtrgm;
- &pgupgrade;
&seg;
&sepgsql;
&contrib-spi;
@@ -135,7 +142,69 @@ CREATE EXTENSION module_name> FROM unpackaged;
&tsearch2;
&unaccent;
&uuid-ossp;
- &vacuumlo;
&xml2;
+
+
+
+
+ Additional Supplied Programs
+
+
+ This appendix and the previous one contain information regarding the modules that
+ can be found in the contrib directory of the
+ PostgreSQL> distribution. See for
+ more information about the contrib section in general and
+ server extensions and plug-ins found in contrib
+ specifically.
+
+
+
+ This appendix covers utility programs found in contrib.
+ Once installed, either from source or a packaging system, they are found in
+ the bin directory of the
+ PostgreSQL installation and can be used like any
+ other program.
+
+
+
+ Client Applications
+
+
+ This section covers PostgreSQL client
+ applications in contrib. They can be run from anywhere,
+ independent of where the database server resides. See
+ also for information about client
+ applications that part of the core PostgreSQL
+ distribution.
+
+
+ &oid2name;
+ &pgbench;
+ &vacuumlo;
+
+
+
+ Server Applications
+
+
+ This section covers PostgreSQL server-related
+ applications in contrib. They are typically run on the
+ host where the database server resides. See also for information about server applications that
+ part of the core PostgreSQL distribution.
+
+
+ &pgarchivecleanup;
+ &pgstandby;
+ &pgtestfsync;
+ &pgtesttiming;
+ &pgupgrade;
+
+
diff --git a/doc/src/sgml/docguide.sgml b/doc/src/sgml/docguide.sgml
index 0b40a57fd99..8aaafb0a340 100644
--- a/doc/src/sgml/docguide.sgml
+++ b/doc/src/sgml/docguide.sgml
@@ -1240,6 +1240,15 @@ save_size.pdfjadetex = 15000
+
+ Author
+
+
+ Author (only used in the contrib section)
+
+
+
+
See Also
diff --git a/doc/src/sgml/oid2name.sgml b/doc/src/sgml/oid2name.sgml
index 3e4fe24a49f..a4c83925aba 100644
--- a/doc/src/sgml/oid2name.sgml
+++ b/doc/src/sgml/oid2name.sgml
@@ -1,12 +1,31 @@
-
- oid2name
+
+
+ oid2name
+ 1
+ Application
+
+
+
+ oid2name
+ resolve OIDs and file nodes in a PostgreSQL data directory
+ oid2name
+
+
+ oid2name
+ option
+
+
+
+
+ Description
+
oid2name> is a utility program that helps administrators to
examine the file structure used by PostgreSQL. To make use of it, you need
@@ -24,19 +43,16 @@
-
- Overview
-
oid2name connects to a target database and
extracts OID, filenode, and/or table name information. You can also have
it show database OIDs or tablespace OIDs.
-
+
-
- oid2name> Options
+
+ Optionsoid2name accepts the following command-line arguments:
@@ -142,9 +158,19 @@
OIDs. Alternatively you can give
-
+
-
+
+ Notes
+
+
+ oid2name> requires a running database server with
+ non-corrupt system catalogs. It is therefore of only limited use
+ for recovering from catastrophic database corruption situations.
+
+
+
+ Examples
@@ -265,24 +291,14 @@ From database "alvherre":
----------------------
155156 foo
-
+
-
- Limitations
-
-
- oid2name> requires a running database server with
- non-corrupt system catalogs. It is therefore of only limited use
- for recovering from catastrophic database corruption situations.
-
-
-
-
+ Author
B. Palmer bpalmer@crimelabs.net
-
+
-
+
diff --git a/doc/src/sgml/pgarchivecleanup.sgml b/doc/src/sgml/pgarchivecleanup.sgml
index 40bac854700..4ae9c45f87f 100644
--- a/doc/src/sgml/pgarchivecleanup.sgml
+++ b/doc/src/sgml/pgarchivecleanup.sgml
@@ -1,12 +1,33 @@
-
- pg_archivecleanup
+
+
+ pg_archivecleanup
+ 1
+ Application
+
+
+
+ pg_archivecleanup
+ clean up PostgreSQL WAL archive files
+ pg_archivecleanup
+
+
+ pg_archivecleanup
+ option
+ archivelocation
+ oldestkeptwalfile
+
+
+
+
+ Description
+
pg_archivecleanup> is designed to be used as an
archive_cleanup_command to clean up WAL file archives when
@@ -15,26 +36,6 @@
clean WAL file archives.
-
- pg_archivecleanup features include:
-
-
-
-
- Written in C, so very portable and easy to install
-
-
-
-
- Easy-to-modify source code, with specifically designated
- sections to modify for your own needs
-
-
-
-
-
- Usage
-
To configure a standby
server to use pg_archivecleanup>, put this into its
@@ -57,14 +58,10 @@ archive_cleanup_command = 'pg_archivecleanup archivelocation> %r'
from the same archive location.
- The full syntax of pg_archivecleanup>'s command line is
-
-pg_archivecleanup option> ... archivelocation> restartwalfile>
-
When used as a standalone program all WAL files logically preceding the
- restartwalfile> will be removed archivelocation>.
+ oldestkeptwalfile> will be removed from archivelocation>.
In this mode, if you specify a .backup> file name, then only the file prefix
- will be used as the restartwalfile>. This allows you to remove
+ will be used as the oldestkeptwalfile>. This allows you to remove
all WAL files archived prior to a specific base backup without error.
For example, the following example will remove all files older than
WAL file name 000000010000003700000010>:
@@ -79,10 +76,10 @@ pg_archivecleanup: removing file "archive/00000001000000370000000E"
archivelocation> is a directory readable and writable by the
server-owning user.
-
+
-
- pg_archivecleanup> Options
+
+ Optionspg_archivecleanup accepts the following command-line arguments:
@@ -124,10 +121,26 @@ pg_archivecleanup: removing file "archive/00000001000000370000000E"
+
-
+
+ Notes
-
+
+ pg_archivecleanup is designed to work with
+ PostgreSQL> 8.0 and later when used as a standalone utility,
+ or with PostgreSQL> 9.0 and later when used as an
+ archive cleanup command.
+
+
+
+ pg_archivecleanup is written in C and has an
+ easy-to-modify source code, with specifically designated sections to modify
+ for your own needs
+
+
+
+ ExamplesOn Linux or Unix systems, you might use:
@@ -151,26 +164,21 @@ archive_cleanup_command = 'pg_archivecleanup -d /mnt/standby/archive %r 2>>clean
+
-
-
-
- Supported Server Versions
-
-
- pg_archivecleanup is designed to work with
- PostgreSQL> 8.0 and later when used as a standalone utility,
- or with PostgreSQL> 9.0 and later when used as an
- archive cleanup command.
-
-
-
-
+ Author
Simon Riggs simon@2ndquadrant.com
-
+
-
+
+ See Also
+
+
+
+
+
+
diff --git a/doc/src/sgml/pgbench.sgml b/doc/src/sgml/pgbench.sgml
index 2ae3b9e317f..16ac69f9ee0 100644
--- a/doc/src/sgml/pgbench.sgml
+++ b/doc/src/sgml/pgbench.sgml
@@ -1,12 +1,37 @@
-
- pgbench
+
+
+ pgbench
+ 1
+ Application
+
+
+
+ pgbench
+ run a benchmark test on PostgreSQL
+ pgbench
+
+
+ pgbench
+
+ option
+ dbname
+
+
+ pgbench
+ option
+ dbname
+
+
+
+
+ Descriptionpgbench is a simple program for running benchmark
tests on PostgreSQL>. It runs the same sequence of SQL
@@ -38,19 +63,16 @@ tps = 85.296346 (excluding connections establishing)
settings. The next line reports the number of transactions completed
and intended (the latter being just the product of number of clients
and number of transactions per client); these will be equal unless the run
- failed before completion. (In -T> mode, only the actual
+ failed before completion. (In
-
- Overview
-
The default TPC-B-like transaction test requires specific tables to be
set up beforehand. pgbench> should be invoked with
- the -i> (initialize) option to create and populate these
+ the
@@ -88,38 +110,37 @@ pgbench_accounts 100000
pgbench_history 0
You can (and, for most purposes, probably should) increase the number
- of rows by using the -s> (scale factor) option. The
- -F> (fillfactor) option might also be used at this point.
+ of rows by using the
-s> (scale factor) option. The
+
-F> (fillfactor) option might also be used at this point.
Once you have done the necessary setup, you can run your benchmark
- with a command that doesn't include -i>, that is
+ with a command that doesn't include
-i>, that is
pgbench options> dbname>
In nearly all cases, you'll need some options to make a useful test.
- The most important options are -c> (number of clients),
- -t> (number of transactions), -T> (time limit),
- and -f> (specify a custom script file).
+ The most important options are
-c> (number of clients),
+
-t> (number of transactions),
-T> (time limit),
+ and
-f> (specify a custom script file).
See below for a full list.
+
+
+
+ Options
- shows options that are used
- during database initialization, while
- shows options that are used
- while running benchmarks, and
- shows options that are useful
- in both cases.
+ The following is divided into three subsections: Different options are used
+ during database initialization and while running benchmarks, some options
+ are useful in both cases.
-
-
-
- pgbench> Initialization Options
+
+ Initialization Optionspgbench accepts the following command-line
@@ -191,10 +212,10 @@ pgbench options> dbname>
-
+
-
- pgbench> Benchmarking Options
+
+ Benchmarking Optionspgbench accepts the following command-line
@@ -237,7 +258,7 @@ pgbench options> dbname>
Define a variable for use by a custom script (see below).
- Multiple -D> options are allowed.
+ Multiple
-D> options are allowed.
@@ -248,7 +269,7 @@ pgbench options> dbname>
Read transaction script from filename>.
See below for details.
- -N, -S, and -f
+
-N
,
-S
, and
-f
are mutually exclusive.
@@ -344,7 +365,7 @@ pgbench options> dbname>
output. With the built-in tests, this is not necessary; the
correct scale factor will be detected by counting the number of
rows in the pgbench_branches> table. However, when testing
- custom benchmarks (-f> option), the scale factor
+ custom benchmarks (
-f> option), the scale factor
will be reported as 1 unless this option is used.
@@ -373,8 +394,8 @@ pgbench options> dbname>
Run the test for this many seconds, rather than a fixed number of
- transactions per client. -t and
- -T are mutually exclusive.
+ transactions per client.
-t
and
+
-T
are mutually exclusive.
@@ -384,7 +405,7 @@ pgbench options> dbname>
Vacuum all four standard tables before running the test.
- With neither -n> nor -v>, pgbench will vacuum the
+ With neither
-n> nor
-v>, pgbench will vacuum the
pgbench_tellers> and pgbench_branches>
tables, and will truncate pgbench_history>.
@@ -394,10 +415,10 @@ pgbench options> dbname>
-
+
-
- pgbench> Common Options
+
+ Common Optionspgbench accepts the following command-line
@@ -435,9 +456,13 @@ pgbench options> dbname>
-
+
+
-
+
+ Notes
+
+ What is the Transaction> Actually Performed in pgbench?
@@ -455,22 +480,22 @@ pgbench options> dbname>
- If you specify -N>, steps 4 and 5 aren't included in the
- transaction. If you specify -S>, only the SELECT> is
+ If you specify
-N>, steps 4 and 5 aren't included in the
+ transaction. If you specify
-S>, only the SELECT> is
issued.
-
+
-
+ Custom Scriptspgbench has support for running custom
benchmark scenarios by replacing the default transaction script
(described above) with a transaction script read from a file
- (-f option). In this case a transaction>
+ (
-f
option). In this case a transaction>
counts as one execution of a script file. You can even specify
- multiple scripts (multiple -f options), in which
+ multiple scripts (multiple
-f
options), in which
case a random one of the scripts is chosen each time a client session
starts a new transaction.
@@ -485,9 +510,9 @@ pgbench options> dbname>
There is a simple variable-substitution facility for script files.
- Variables can be set by the command-line -D> option,
+ Variables can be set by the command-line
-D> option,
explained above, or by the meta commands explained below.
- In addition to any variables preset by -D> command-line options,
+ In addition to any variables preset by
-D> command-line options,
the variable scale> is preset to the current scale factor.
Once set, a variable's
value can be inserted into a SQL command by writing
@@ -648,17 +673,17 @@ END;
otherwise they'd not be independently touching different rows.)
-
+
-
+ Per-Transaction Logging
- With the -l> option, pgbench> writes the time
+ With the
-l> option, pgbench> writes the time
taken by each transaction to a log file. The log file will be named
pgbench_log.nnn>, where
nnn> is the PID of the pgbench process.
- If the -j> option is 2 or higher, creating multiple worker
+ If the
-j> option is 2 or higher, creating multiple worker
threads, each will have its own log file. The first worker will use the
same name for its log file as in the standard single worker case.
The additional log files for the other workers will be named
@@ -676,7 +701,7 @@ END;
where time> is the total elapsed transaction time in microseconds,
file_no> identifies which script file was used
- (useful when multiple scripts were specified with -f>),
+ (useful when multiple scripts were specified with
-f>),
and time_epoch>/time_us> are a
UNIX epoch format timestamp and an offset
in microseconds (suitable for creating a ISO 8601
@@ -693,13 +718,13 @@ END;
0 202 2038 0 1175850569 2663
-
+
-
+ Per-Statement Latencies
- With the -r> option, pgbench> collects
+ With the
-r> option, pgbench> collects
the elapsed transaction time of each statement executed by every
client. It then reports an average of those values, referred to
as the latency for each statement, after the benchmark has finished.
@@ -749,9 +774,9 @@ statement latencies in milliseconds:
Comparing average TPS values with and without latency reporting enabled
is a good way to measure if the timing overhead is significant.
-
+
-
+ Good Practices
@@ -762,7 +787,7 @@ statement latencies in milliseconds:
In the first place, never> believe any test that runs
- for only a few seconds. Use the -t> or -T> option
+ for only a few seconds. Use the
-t> or
-T> option
to make the run last at least a few minutes, so as to average out noise.
In some cases you could need hours to get numbers that are reproducible.
It's a good idea to try the test run a few times, to find out if your
@@ -771,11 +796,11 @@ statement latencies in milliseconds:
For the default TPC-B-like test scenario, the initialization scale factor
- (-s>) should be at least as large as the largest number of
- clients you intend to test (-c>); else you'll mostly be
- measuring update contention. There are only -s> rows in
+ (
-s>) should be at least as large as the largest number of
+ clients you intend to test (
-c>); else you'll mostly be
+ measuring update contention. There are only
-s> rows in
the pgbench_branches> table, and every transaction wants to
- update one of them, so -c> values in excess of -s>
+ update one of them, so
-c> values in excess of
-s>
will undoubtedly result in lots of transactions blocked waiting for
other transactions.
@@ -798,6 +823,6 @@ statement latencies in milliseconds:
instances concurrently, on several client machines, against the same
database server.
-
-
-
+
+
+
diff --git a/doc/src/sgml/pgstandby.sgml b/doc/src/sgml/pgstandby.sgml
index e698cb73e63..0fe3f646bc0 100644
--- a/doc/src/sgml/pgstandby.sgml
+++ b/doc/src/sgml/pgstandby.sgml
@@ -1,12 +1,35 @@
-
- pg_standby
+
+
+ pg_standby
+ 1
+ Application
+
+
+
+ pg_standby
+ supports the creation of a PostgreSQL warm standby server
+ pg_standby
+
+
+ pg_standby
+ option
+ archivelocation
+ nextwalfile
+ xlogfilepath
+ restartwalfile
+
+
+
+
+ Description
+
pg_standby> supports creation of a warm standby>
database server. It is designed to be a production-ready program, as well
@@ -21,31 +44,6 @@
server manual (see ).
-
- pg_standby features include:
-
-
-
-
- Written in C, so very portable and easy to install
-
-
-
-
- Easy-to-modify source code, with specifically designated
- sections to modify for your own needs
-
-
-
-
- Already tested on Linux and Windows
-
-
-
-
-
- Usage
-
To configure a standby
server to use pg_standby>, put this into its
@@ -56,16 +54,6 @@ restore_command = 'pg_standby archiveDir> %f %p %r'
where archiveDir> is the directory from which WAL segment
files should be restored.
-
- The full syntax of pg_standby>'s command line is
-
-pg_standby option> ... archivelocation> nextwalfile> xlogfilepath> restartwalfile>
-
- When used within restore_command>, the %f> and
- %p> macros should be specified for nextwalfile>
- and xlogfilepath> respectively, to provide the actual file
- and path required for the restore.
-
If restartwalfile> is specified, normally by using the
%r macro, then all WAL files logically preceding this
@@ -118,10 +106,10 @@ pg_standby option> ... archiv
-
+
-
- pg_standby> Options
+
+ Optionspg_standby accepts the following command-line arguments:
@@ -226,9 +214,36 @@ pg_standby option> ... archiv
-
+
-
+
+ Notes
+
+
+ pg_standby is designed to work with
+ PostgreSQL> 8.2 and later.
+
+
+ PostgreSQL> 8.3 provides the %r macro,
+ which is designed to let pg_standby know the
+ last file it needs to keep. With PostgreSQL> 8.2, the
+ -k option must be used if archive cleanup is
+ required. This option remains available in 8.3, but its use is deprecated.
+
+
+ PostgreSQL> 8.4 provides the
+ recovery_end_command> option. Without this option
+ a leftover trigger file can be hazardous.
+
+
+
+ pg_standby is written in C and has an
+ easy-to-modify source code, with specifically designated sections to modify
+ for your own needs
+
+
+
+ ExamplesOn Linux or Unix systems, you might use:
@@ -339,35 +354,21 @@ recovery_end_command = 'del C:\pgsql.trigger.5442'
network.
-
+
-
- Supported Server Versions
-
-
- pg_standby is designed to work with
- PostgreSQL> 8.2 and later.
-
-
- PostgreSQL> 8.3 provides the %r macro,
- which is designed to let pg_standby know the
- last file it needs to keep. With PostgreSQL> 8.2, the
- -k option must be used if archive cleanup is
- required. This option remains available in 8.3, but its use is deprecated.
-
-
- PostgreSQL> 8.4 provides the
- recovery_end_command> option. Without this option
- a leftover trigger file can be hazardous.
-
-
-
-
+ Author
Simon Riggs simon@2ndquadrant.com
-
+
-
+
+ See Also
+
+
+
+
+
+
diff --git a/doc/src/sgml/pgtestfsync.sgml b/doc/src/sgml/pgtestfsync.sgml
index 9e17b049908..ad5ddeb2288 100644
--- a/doc/src/sgml/pgtestfsync.sgml
+++ b/doc/src/sgml/pgtestfsync.sgml
@@ -1,12 +1,31 @@
-
- pg_test_fsync
+
+
+ pg_test_fsync
+ 1
+ Application
+
+
+
+ pg_test_fsync
+ determine fastest wal_sync_method for PostgreSQL
+ pg_test_fsync
+
+
+ pg_test_fsync
+ option
+
+
+
+
+ Description
+
pg_test_fsync> is intended to give you a reasonable
idea of what the fastest is on your
@@ -17,13 +36,10 @@
since many database servers are not speed-limited by their transaction
logs.
+
-
- Usage
-
-
-pg_test_fsync [options]
-
+
+ Optionspg_test_fsync accepts the following
@@ -62,14 +78,21 @@ pg_test_fsync [options]
-
+
-
+ Author
Bruce Momjian bruce@momjian.us
-
+
-
+
+ See Also
+
+
+
+
+
+
diff --git a/doc/src/sgml/pgtesttiming.sgml b/doc/src/sgml/pgtesttiming.sgml
index 86af4e28dc0..586611f6f41 100644
--- a/doc/src/sgml/pgtesttiming.sgml
+++ b/doc/src/sgml/pgtesttiming.sgml
@@ -1,25 +1,41 @@
-
- pg_test_timing
+
+
+ pg_test_timing
+ 1
+ Application
+
+
+
+ pg_test_timing
+ measure timing overhead
+ pg_test_timing
+
+
+ pg_test_timing
+ option
+
+
+
+
+ Description
+
pg_test_timing> is a tool to measure the timing overhead
on your system and confirm that the system time never moves backwards.
Systems that are slow to collect timing data can give less accurate
EXPLAIN ANALYZE results.
+
-
- Usage
-
-
-pg_test_timing [options]
-
+
+ Optionspg_test_timing accepts the following
@@ -43,9 +59,12 @@ pg_test_timing [options]
-
+
-
+
+ Usage
+
+ Interpreting results
@@ -74,8 +93,8 @@ Histogram of timing durations:
one microsecond (usec).
-
-
+
+ Measuring executor timing overhead
@@ -103,8 +122,9 @@ EXPLAIN ANALYZE SELECT COUNT(*) FROM t;
timing overhead would be less problematic.
-
-
+
+
+ Changing time sources
On some newer Linux systems, it's possible to change the clock
@@ -178,8 +198,8 @@ Histogram of timing durations:
1: 27694571 90.23734%
-
-
+
+ Clock hardware and timing accuracy
@@ -248,14 +268,22 @@ Histogram of timing durations:
Programmable Interrupt Controller (APIC) timer, and the Cyclone
timer. These timers aim for millisecond resolution.
-
+
+
-
+ Author
Ants Aasma ants.aasma@eesti.ee
-
+
-
+
+ See Also
+
+
+
+
+
+
diff --git a/doc/src/sgml/pgupgrade.sgml b/doc/src/sgml/pgupgrade.sgml
index 6ecdfda6719..ef99212b0fd 100644
--- a/doc/src/sgml/pgupgrade.sgml
+++ b/doc/src/sgml/pgupgrade.sgml
@@ -1,12 +1,39 @@
-
- pg_upgrade
+
+
+ pg_upgrade
+ 1
+ Application
+
+
+
+ pg_upgrade
+ upgrade a PostgreSQL server instance
+ pg_upgrade
+
+
+ pg_upgrade
+
-b
+ oldbindir
+
-B
+ newbindir
+
-d
+ olddatadir
+
-D
+ newdatadir
+ option
+
+
+
+
+ Description
+
pg_upgrade> (formerly called pg_migrator>) allows data
stored in PostgreSQL> data files to be upgraded to a later PostgreSQL>
@@ -37,19 +64,14 @@
be checked by pg_upgrade>.
-
- Supported Versions
-
pg_upgrade supports upgrades from 8.3.X and later to the current
major release of PostgreSQL>, including snapshot and alpha releases.
-
+
-
-
-
- pg_upgrade> Options
+
+ Optionspg_upgrade accepts the following command-line arguments:
@@ -160,10 +182,15 @@
-
+
-
- Upgrade Steps
+
+ Usage
+
+
+ These are the steps to perform an upgrade
+ with pg_upgrade:
+
@@ -459,13 +486,54 @@ psql --username postgres --file script.sql postgres
-
+
-
- Limitations in Upgrading from> PostgreSQL 8.3
+
+ Notes
- Upgrading from PostgreSQL 8.3 has additional restrictions not present
+ pg_upgrade> does not support upgrading of databases
+ containing these reg*> OID-referencing system data types:
+ regproc>, regprocedure>, regoper>,
+ regoperator>, regconfig>, and
+ regdictionary>. (regtype> can be upgraded.)
+
+
+
+ All failure, rebuild, and reindex cases will be reported by
+ pg_upgrade> if they affect your installation;
+ post-upgrade scripts to rebuild tables and indexes will be
+ generated automatically.
+
+
+
+ For deployment testing, create a schema-only copy of the old cluster,
+ insert dummy data, and upgrade that.
+
+
+
+ If you are upgrading a pre-PostgreSQL> 9.2 cluster
+ that uses a configuration-file-only directory, you must pass the
+ real data directory location to pg_upgrade>, and
+ pass the configuration directory location to the server, e.g.
+ -d /real-data-directory -o '-D /configuration-directory'>.
+
+
+
+ If you want to use link mode and you do not want your old cluster
+ to be modified when the new cluster is started, make a copy of the
+ old cluster and upgrade that in link mode. To make a valid copy
+ of the old cluster, use rsync> to create a dirty
+ copy of the old cluster while the server is running, then shut down
+ the old server and run rsync> again to update the copy with any
+ changes to make it consistent.
+
+
+
+ Limitations in Upgrading PostgreSQL 8.3
+
+
+ Upgrading from PostgreSQL 8.3 has additional restrictions not present
when upgrading from later PostgreSQL releases. For example,
pg_upgrade will not work for upgrading from 8.3 if a user column
is defined as:
@@ -534,49 +602,18 @@ psql --username postgres --file script.sql postgres
possible to upgrade from the MSI installer to the one-click installer.
-
+
-
- Notes
+
-
- pg_upgrade> does not support upgrading of databases
- containing these reg*> OID-referencing system data types:
- regproc>, regprocedure>, regoper>,
- regoperator>, regconfig>, and
- regdictionary>. (regtype> can be upgraded.)
-
+
+ See Also
-
- All failure, rebuild, and reindex cases will be reported by
- pg_upgrade> if they affect your installation;
- post-upgrade scripts to rebuild tables and indexes will be
- generated automatically.
-
-
-
- For deployment testing, create a schema-only copy of the old cluster,
- insert dummy data, and upgrade that.
-
-
-
- If you are upgrading a pre-PostgreSQL> 9.2 cluster
- that uses a configuration-file-only directory, you must pass the
- real data directory location to pg_upgrade>, and
- pass the configuration directory location to the server, e.g.
- -d /real-data-directory -o '-D /configuration-directory'>.
-
-
-
- If you want to use link mode and you do not want your old cluster
- to be modified when the new cluster is started, make a copy of the
- old cluster and upgrade that in link mode. To make a valid copy
- of the old cluster, use rsync> to create a dirty
- copy of the old cluster while the server is running, then shut down
- the old server and run rsync> again to update the copy with any
- changes to make it consistent.
-
-
-
-
-
+
+
+
+
+
+
+
+
diff --git a/doc/src/sgml/stylesheet-man.xsl b/doc/src/sgml/stylesheet-man.xsl
index 195c892c0b1..f5c890ef609 100644
--- a/doc/src/sgml/stylesheet-man.xsl
+++ b/doc/src/sgml/stylesheet-man.xsl
@@ -30,6 +30,16 @@
+
+
+ <
+
+ >
+
+
+
diff --git a/doc/src/sgml/vacuumlo.sgml b/doc/src/sgml/vacuumlo.sgml
index 97753de6c0c..4640744e8b7 100644
--- a/doc/src/sgml/vacuumlo.sgml
+++ b/doc/src/sgml/vacuumlo.sgml
@@ -1,12 +1,32 @@
-
- vacuumlo
+
+
+ vacuumlo
+ 1
+ Application
+
+
+
+ vacuumlo
+ remove orphaned large objects from a PostgreSQL database
+ vacuumlo
+
+
+ vacuumlo
+ option
+ dbname
+
+
+
+
+ Description
+
vacuumlo> is a simple utility program that will remove any
orphaned> large objects from a
@@ -22,30 +42,19 @@
to avoid creating orphaned LOs in the first place.
-
- Usage
-
-
-vacuumlo [options] database [database2 ... databaseN]
-
-
- All databases named on the command line are processed. Available options
- include:
+ All databases named on the command line are processed.
+
+
+
+ Options
-
-v
+
-h
hostname>
- Write a lot of progress messages.
-
-
-
-
-
-n
-
- Don't remove anything, just show what would be done.
+ Database server's host.
@@ -62,6 +71,20 @@ vacuumlo [options] database [database2 ... databaseN]
+
+
-n
+
+ Don't remove anything, just show what would be done.
+
+
+
+
+
port>
-
- Database server's port.
-
-
-
+
-
- Method
+
+ Notes
+ vacuumlo works by the following method:
First, vacuumlo> builds a temporary table which contains all
- of the OIDs of the large objects in the selected database.
+ of the OIDs of the large objects in the selected database. It then scans
+ through all columns in the database that are of type
+ oid> or lo>, and removes matching entries from the temporary
+ table. (Note: Only types with these names are considered; in particular,
+ domains over them are not considered.) The remaining entries in the
+ temporary table identify orphaned LOs. These are removed.
+
-
- It then scans through all columns in the database that are of type
- oid> or lo>, and removes matching entries from the
- temporary table. (Note: only types with these names are considered;
- in particular, domains over them are not considered.)
-
-
-
- The remaining entries in the temporary table identify orphaned LOs.
- These are removed.
-
-
-
-
+ Author
Peter Mount peter@retep.org.uk
-
+
-
+