Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Configuration patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: pgsql(at)mohawksoft(dot)com,PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] Configuration patch
Date: 2004-06-03 16:47:34
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>> 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.

AFAICS this patch breaks standalone backends, since the smarts involved
in dealing with the new flavors of directory layouts were not taught to

The documentation is rather lacking as well.  "include" is not really a
variable and should not be documented as if it were --- for one thing,
that leaves the reader wondering if he can only specify it once.  The
other added variables are insufficiently doc'd because there is no
explanation of the defaults.  Also I should think that somewhere in the
admin guide there should be an explanation of the different ways you can
lay out the files and why you might choose different ones.  It's also
highly unclear how you get such a setup established, when there's been
no change in the behavior of initdb.

ProcessConfigFile will dump core on out-of-memory (test for malloc
failure is in the wrong place).  I also think some memory leaks have
been introduced in ReadConfigFile.

The whole concept of a "function" GUC variable seems very ill-advised to
me; for one thing, what will "show include" or "set include" do?  Can a
user do ALTER USER SET include = foo?  I think it would have been better
to hard-wire the handling of 'include' in the guc file reader, and not
try to make it act like a variable.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: pgsqlDate: 2004-06-03 17:46:09
Subject: Re: [HACKERS] Configuration patch
Previous:From: Gaetano MendolaDate: 2004-06-03 16:25:54
Subject: Re: PageGetMaxOffsetNumber on uninitialized pages

pgsql-patches by date

Next:From: Alvaro HerreraDate: 2004-06-03 17:00:51
Subject: Re: fix oid casting inconsistency
Previous:From: Bruce MomjianDate: 2004-06-03 14:55:45
Subject: Re: Compiling libpq with VisualC

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group