Configuration patch - Mailing list pgsql-hackers

From pgsql@mohawksoft.com
Subject Configuration patch
Date
Msg-id 16882.24.91.171.78.1084385452.squirrel@mail.mohawksoft.com
Whole thread Raw
Responses Re: Configuration patch
List pgsql-hackers
This patch incorporates a number of changes suggested by the group. The
purpose of this patch is to move postgresql to a position where all
configuration options are specified in one place. The postgresql.conf file
could completely document a postgresql environment.


It adds this functionality:

The "-D' option will work as it always has if it is set to a standard
postgresql database cluster directory. If it is set to a "postgresql.conf"
file, it will use that file for configuration. If it is set to a directory
which is not a cluster directory, i.e. "/somepath/etc" it will look for
pg_hba.conf, pg_ident.conf, and postgresql.conf there.

For postgresql to work only with a configuration file, some options have
been added:

include = '/etc/postgres/debug.conf'
pgdata = '/vol01/postgres'
hba_conf = '/etc/postgres/pg_hba_conf'
ident_conf = '/etc/postgres/pg_ident.conf'
runtime_pidfile = '/var/run/postgresql.conf'
tablespace = '/somevol/somepath'

"include" allows files with configuration parameters to be included.

"pgdata" (used to be data_dir in old patch) tells PostgreSQL where it's
database cluster directory is located.

"hba_conf" tells PostgreSQL where to find pg_hba.conf file.

"ident_conf" tells PostgreSQL where to find pg_ident.conf.

"runtime_pidfile" tells postgres to write it's PID to a file that would be
used by external applications. It is *NOT* the pid file which postgresql
uses.

"tablespace" allows postgresql to use alternate locations without
environment variables. Using SIGHUP, tablespaces are reloaded. This allows
you to add tablespaces to a running PostgreSQL process. (I know this has a
limited lifetime, but it may make "CREATE DATABASE ... WITH LOCATION" a
little bit more sane in the meantime.

Attachment

pgsql-hackers by date:

Previous
From: Larry Rosenman
Date:
Subject: Re: threads stuff/UnixWare
Next
From: Tom Lane
Date:
Subject: Re: Probably security hole in postgresql-7.4.1