Alvaro Herrera writes:
> Excerpts from Tom Lane's message of mié sep 07 14:49:45 -0300 2011:
>> I don't think we can just s/DEBUG3/LOG/, because of the
>> log clutter that will result when they all think there's a problem.
> I was thinking that the solution would be to promote DEBUG3 to LOG in
>
On 09/07/2011 03:18 PM, Robert Haas wrote:
Yeah, I guess we don't have many good short-term options. I continue
to think that this whole facility is mis-designed, though.
I agree. I have tripped over it several times.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
On Wed, Sep 7, 2011 at 2:21 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Sep 7, 2011 at 2:05 PM, Tom Lane wrote:
>>> The ones in auto_explain and pg_stat_statements aren't too problematic
>>> because those modules are designed to be preloaded by the postmaster.
>>> We've avoided adding s
Excerpts from Tom Lane's message of mié sep 07 14:49:45 -0300 2011:
> Alvaro Herrera writes:
> > Another thing we detected some days ago is that a custom variable in a
> > module not loaded by postmaster, does not seem to get reported
> > appropriately when an invalid value is set on postgresql.co
Robert Haas writes:
> On Wed, Sep 7, 2011 at 2:05 PM, Tom Lane wrote:
>> The ones in auto_explain and pg_stat_statements aren't too problematic
>> because those modules are designed to be preloaded by the postmaster.
>> We've avoided adding such variables in modules that aren't intended
>> to be
On Wed, Sep 7, 2011 at 2:05 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Sep 7, 2011 at 1:55 PM, Tom Lane wrote:
>>> You can't set a custom SUSET variable in advance of loading the module,
>>> because the system has no way to know it should enforce superuser
>>> restrictions on setting i
Robert Haas writes:
> On Wed, Sep 7, 2011 at 1:55 PM, Tom Lane wrote:
>> You can't set a custom SUSET variable in advance of loading the module,
>> because the system has no way to know it should enforce superuser
>> restrictions on setting it. For the most part, this is a good reason to
>> avoid
On Wed, Sep 7, 2011 at 1:55 PM, Tom Lane wrote:
> Pavel Stehule writes:
>> When we have a custom SUSET variable, like plpgsql.variable_conflikt,
>> then setting this variable before plpgsql initalisation raises a
>> exception, but it raise a exception when some plpgsql function is
>> created. Try
Pavel Stehule writes:
> When we have a custom SUSET variable, like plpgsql.variable_conflikt,
> then setting this variable before plpgsql initalisation raises a
> exception, but it raise a exception when some plpgsql function is
> created. Try to execute a attached script - a set statement is ok,
Alvaro Herrera writes:
> Another thing we detected some days ago is that a custom variable in a
> module not loaded by postmaster, does not seem to get reported
> appropriately when an invalid value is set on postgresql.conf and
> reloaded: backends report problems with DEBUG3, only postmaster use
Excerpts from Pavel Stehule's message of mié sep 07 14:23:43 -0300 2011:
> Hello
>
> Andy Colson found a bug in GUC implementation.
>
> When we have a custom SUSET variable, like plpgsql.variable_conflikt,
> then setting this variable before plpgsql initalisation raises a
> exception, but it rais
Hello
Andy Colson found a bug in GUC implementation.
When we have a custom SUSET variable, like plpgsql.variable_conflikt,
then setting this variable before plpgsql initalisation raises a
exception, but it raise a exception when some plpgsql function is
created. Try to execute a attached script -
12 matches
Mail list logo
