pgsql: Make configuration parameters fall back to their default values
Log Message:
-----------
Make configuration parameters fall back to their default values when they
are removed from the configuration file.
Joachim Wieland
Modified Files:
--------------
pgsql/src/backend/access/transam:
xact.c (r1.234 -> r1.235)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/xact.c.diff?r1=1.234&r2=1.235)
pgsql/src/backend/utils/misc:
guc-file.l (r1.47 -> r1.48)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/guc-file.l.diff?r1=1.47&r2=1.48)
guc.c (r1.379 -> r1.380)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/guc.c.diff?r1=1.379&r2=1.380)
pgsql/src/include/utils:
guc_tables.h (r1.30 -> r1.31)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/utils/guc_tables.h.diff?r1=1.30&r2=1.31)
petere@postgresql.org (Peter Eisentraut) writes:
Make configuration parameters fall back to their default values when they
are removed from the configuration file.
It appears that this patch has broken custom GUC variables; at the very
least it's broken plperl.
regards, tom lane
"Tom Lane" <tgl@sss.pgh.pa.us> writes:
petere@postgresql.org (Peter Eisentraut) writes:
Make configuration parameters fall back to their default values when they
are removed from the configuration file.It appears that this patch has broken custom GUC variables; at the very
least it's broken plperl.
Huh, it occurs to me that I haven't seen any plperl regression tests fly by
when I've been running regression tests myself. What do I have to do to test
if plperl, plpython, etc work with the packed varlena patch?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Gregory Stark wrote:
"Tom Lane" <tgl@sss.pgh.pa.us> writes:
petere@postgresql.org (Peter Eisentraut) writes:
Make configuration parameters fall back to their default values when
they
are removed from the configuration file.It appears that this patch has broken custom GUC variables; at the very
least it's broken plperl.Huh, it occurs to me that I haven't seen any plperl regression tests fly
by
when I've been running regression tests myself. What do I have to do to
test
if plperl, plpython, etc work with the packed varlena patch?
cd src/pl; make installcheck
cheers
andrew
Gregory Stark <stark@enterprisedb.com> writes:
Huh, it occurs to me that I haven't seen any plperl regression tests fly by
when I've been running regression tests myself. What do I have to do to test
if plperl, plpython, etc work with the packed varlena patch?
cd to $TOP/src/pl, run "make installcheck". Make sure you have
configured --with all the PLs you want to test.
regards, tom lane
On Mon, Mar 12, 2007 at 08:20:53PM -0500, Andrew Dunstan wrote:
Gregory Stark wrote:
"Tom Lane" <tgl@sss.pgh.pa.us> writes:
petere@postgresql.org (Peter Eisentraut) writes:
Make configuration parameters fall back to their default values when
they
are removed from the configuration file.It appears that this patch has broken custom GUC variables; at the very
least it's broken plperl.Huh, it occurs to me that I haven't seen any plperl regression tests fly
by
when I've been running regression tests myself. What do I have to do to
test
if plperl, plpython, etc work with the packed varlena patch?cd src/pl; make installcheck
Is there any particular reason why we don't run these as part of a
general "make check"?
//Magnus
Magnus Hagander wrote:
On Mon, Mar 12, 2007 at 08:20:53PM -0500, Andrew Dunstan wrote:
Gregory Stark wrote:
"Tom Lane" <tgl@sss.pgh.pa.us> writes:
petere@postgresql.org (Peter Eisentraut) writes:
Make configuration parameters fall back to their default values when
they
are removed from the configuration file.It appears that this patch has broken custom GUC variables; at the very
least it's broken plperl.Huh, it occurs to me that I haven't seen any plperl regression tests fly
by
when I've been running regression tests myself. What do I have to do to
test
if plperl, plpython, etc work with the packed varlena patch?cd src/pl; make installcheck
Is there any particular reason why we don't run these as part of a
general "make check"?//Magnus
Probably historical more than anything else.
The core tests all run regardless of configuration, though, and the PL
tests use a different database (by design). When we standardised this we
did just enough to enable the buildfarm clients to test PLs sanely. If
you think we need more, have a go at it.
I should perhaps point out that the buildfarm client can be used to do a
comprehensive build and test on your sources, including all the
configured PLs, ECPG and the contrib tests, using either the
--from-source or --from-source-clean flags. These were originally
designed to help diagnose and fix problems disclosed during normal
buildfarm runs, but I have found it quite useful when working on
substantial projects. You don't need to be registered as a buildfarm
member to use the client program, in these modes - no results are
uploaded to the server when these flags are used.
cheers
andrew