This chapter is dedicated to all database administrators and to those who

want to become PostgreSQL administrators. Database administration can

be either a simple or a difficult task, depending on the demands your
database has to face and the level of security you have to provide.
PostgreSQL is indeed a database system that can easily be administered
as long as the database administrator ( D B A ) understands the basic
concepts of databases, backup strategies, and security issues. Security
demands are always increasing and it is necessary to have a high standard
for security, even if your database is only used in a protected
environment. But let's get to some practical stuff.
Configuring the Postmaster
The heart of every PostgreSQL database server is the so called
“postmaster, the supervisor daemon of your database. The postmaster has
PREV
5. PL/PGSQL ⏮
NEXT
7. Backup and Recovery ⏭

 PostgreSQL Developer's Handbook

⬆
8/17/2019 6. Database Administration - PostgreSQL Developer's Handbook
https://learning.oreilly.com/library/view/postgresql-developers-handbook/0672322609/ch06.html 2/40
a lot of parameters that can be configured to make your database run
better and faster.
By using
postmaster --help
we can get a little help about working with the postmaster.
On Unix systems, the postmaster is usually started when the default
runlevel starts its processes, but it can also be started manually. No
matter how the postmaster is started, you can use the flags just shown.
Let's take a closer look at some flags.
-B. Defines the number of shared memory buffers PostgreSQL uses
for the backend processes. One shared memory buffer is usually
8KB, but the size can be redefined in src/include/config.h
(see BLCKSZ).
-D. Specifies the directory PostgreSQL will use for the data. -D
defines the root directory of a cluster of databases. If the database
directories are not defined via the shell, PostgreSQL will use the
environment variable $PGDATA instead. If you want to set this
variable, check out your Unix manual and look for the export
command (Bourne Shell).
-N. Sets the maximum number of backend processes that are
allowed to run on the machine. The default value is set to 32 but can
also be changed in src/include/config.h.
-S. Starts the postmaster in silent mode, which means that all
messages the postmaster normally produces—no matter whether on
standard output or standard error—are redirected to /dev/null.
This is extremely bad for troubleshooting because you will loose
important information.
-d. Defines the debugging level your PostgreSQL server will use.
The debugging level can be set from 1 to 5. The higher the
debugging level is, the more information will be displayed. In most
cases, it is useful to redirect the output to a file because this is the
only way to get a complete history of what is going

Name

vacuumlo -- remove orphaned large objects from a PostgreSQL database

Synopsis

vacuumlo [option...] dbname...

Description

vacuumlo is a simple utility program that will remove any "orphaned" large objects from
a PostgreSQL database. An orphaned large object (LO) is considered to be any LO whose OID does
not appear in any oid or lo data column of the database.
If you use this, you may also be interested in the lo_manage trigger in
the lo module. lo_manage is useful to try to avoid creating orphaned LOs in the first place.
All databases named on the command line are processed.

Options

vacuumlo accepts the following command-line arguments:

-l limit
Remove no more than limit large objects per transaction (default 1000). Since the server acquires
a lock per LO removed, removing too many LOs in one transaction risks
exceeding max_locks_per_transaction. Set the limit to zero if you want all removals done in a single
transaction.
-n
Don't remove anything, just show what would be done.
-v
Write a lot of progress messages.
-V
--version
Print the vacuumlo version and exit.
-?
--help
Show help about vacuumlo command line arguments, and exit.
vacuumlo also accepts the following command-line arguments for connection parameters:
-h hostname
Database server's host.
-p port
Database server's port.
-U username
User name to connect as.
-w
--no-password
Never issue a password prompt. If the server requires password authentication and a password is
not available by other means such as a .pgpass file, the connection attempt will fail. This option
can be useful in batch jobs and scripts where no user is present to enter a password.
-W
Force vacuumlo to prompt for a password before connecting to a database.
This option is never essential, since vacuumlo will automatically prompt for a password if the
server demands password authentication. However, vacuumlo will waste a connection
attempt finding out that the server wants a password. In some cases it is worth typing -W to
avoid the extra connection attempt.
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. 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>

Prev Home Next

oid2name