Re: custom variables and PGC_SUSET issue

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, ash(at)commandprompt(dot)com
Subject: Re: custom variables and PGC_SUSET issue
Date: 2011-09-07 17:49:45
Message-ID: 26348.1315417785@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)commandprompt(dot)com> 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 uses
> LOG, but since postmaster isn't loading the module, nothing happens.

This is just an instance of the general problem that the current design
assumes all processes will have the same opinion about the validity of
settings read from postgresql.conf. We discussed that back in July:
http://archives.postgresql.org/pgsql-hackers/2011-07/msg00850.php
but it wasn't clear to me that any consensus had been reached about how
to change the behavior. I proposed that we should let processes adopt
individual settings even if they thought other ones were invalid; that
gets rid of some of the issues, but it doesn't really address how we
should report problems when only some of the processes think there's a
problem. 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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-09-07 17:55:11 Re: custom variables and PGC_SUSET issue
Previous Message Bruce Momjian 2011-09-07 17:48:37 Re: Large C files