Thread: Re: [COMMITTERS] pgsql: Make configuration parameters fall back to their default values
Re: [COMMITTERS] pgsql: Make configuration parameters fall back to their default values
From
Tom Lane
Date:
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
Re: [COMMITTERS] pgsql: Make configuration parameters fall back to their default values
From
Gregory Stark
Date:
"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
Re: [COMMITTERS] pgsql: Make configuration parameters fall back to their default values
From
"Andrew Dunstan"
Date:
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
Re: [COMMITTERS] pgsql: Make configuration parameters fall back to their default values
From
Tom Lane
Date:
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
Re: [COMMITTERS] pgsql: Make configuration parameters fall back to their default values
From
Magnus Hagander
Date:
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
Re: [COMMITTERS] pgsql: Make configuration parameters fall back to their default values
From
Andrew Dunstan
Date:
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