Lists: | pgsql-committerspgsql-hackers |
---|
From: | petere(at)postgresql(dot)org (Peter Eisentraut) |
---|---|
To: | pgsql-committers(at)postgresql(dot)org |
Subject: | pgsql: Make configuration parameters fall back to their default values |
Date: | 2007-03-12 22:09:28 |
Message-ID: | 20070312220928.6EE1C9FB51C@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-committers pgsql-hackers |
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)
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Joachim Wieland <joe(at)mcknight(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [COMMITTERS] pgsql: Make configuration parameters fall back to their default values |
Date: | 2007-03-13 00:38:11 |
Message-ID: | 15712.1173746291@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-committers pgsql-hackers |
petere(at)postgresql(dot)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
From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "Joachim Wieland" <joe(at)mcknight(dot)de>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [COMMITTERS] pgsql: Make configuration parameters fall back to their default values |
Date: | 2007-03-13 01:13:15 |
Message-ID: | 87abyiosic.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-committers pgsql-hackers |
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> petere(at)postgresql(dot)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
From: | "Andrew Dunstan" <andrew(at)dunslane(dot)net> |
---|---|
To: | "Gregory Stark" <stark(at)enterprisedb(dot)com> |
Cc: | "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "Joachim Wieland" <joe(at)mcknight(dot)de>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [COMMITTERS] pgsql: Make configuration parameters fall back to their default values |
Date: | 2007-03-13 01:20:53 |
Message-ID: | 62710.75.177.135.163.1173748853.squirrel@www.dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-committers pgsql-hackers |
Gregory Stark wrote:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>
>> petere(at)postgresql(dot)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
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "Joachim Wieland" <joe(at)mcknight(dot)de>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [COMMITTERS] pgsql: Make configuration parameters fall back to their default values |
Date: | 2007-03-13 01:26:10 |
Message-ID: | 22250.1173749170@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-committers pgsql-hackers |
Gregory Stark <stark(at)enterprisedb(dot)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
From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Gregory Stark <stark(at)enterprisedb(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Joachim Wieland <joe(at)mcknight(dot)de>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [COMMITTERS] pgsql: Make configuration parameters fall back to their default values |
Date: | 2007-03-13 08:44:43 |
Message-ID: | 20070313084443.GC22636@svr2.hagander.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-committers pgsql-hackers |
On Mon, Mar 12, 2007 at 08:20:53PM -0500, Andrew Dunstan wrote:
> Gregory Stark wrote:
> > "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> >
> >> petere(at)postgresql(dot)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
From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Gregory Stark <stark(at)enterprisedb(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Joachim Wieland <joe(at)mcknight(dot)de>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [COMMITTERS] pgsql: Make configuration parameters fall back to their default values |
Date: | 2007-03-13 13:46:07 |
Message-ID: | 45F6AB1F.3000400@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-committers pgsql-hackers |
Magnus Hagander wrote:
> On Mon, Mar 12, 2007 at 08:20:53PM -0500, Andrew Dunstan wrote:
>
>> Gregory Stark wrote:
>>
>>> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>>>
>>>
>>>> petere(at)postgresql(dot)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