Re: pg_file_settings view vs. Windows - Mailing list pgsql-hackers

On Mon, Jun 29, 2015 at 12:20 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
>> I noticed that in EXEC_BACKEND builds (ie, Windows) the pg_file_settings
>> view doesn't act as its author presumably intended.  Specifically, it
>> reads as empty until/unless the current session processes a SIGHUP event.
>> ...
>> More or less bad alternative answers include:
>> ...
>> 3. Force a SIGHUP processing cycle but don't actually apply any of the
>> values.  This would be pretty messy though, especially if you wanted it
>> to produce results exactly like the normal case so far as detection of
>> incorrect values goes.  I don't think this is a good idea; it's going
>> to be too prone to corner-case bugs.
>
> I had second thoughts about how difficult this might be.  I had forgotten
> that set_config_option already has a changeVal argument that does more or
> less exactly what we need here: if false, it makes all the checks but
> doesn't actually apply the value.
>
> So let me make a radical proposal that both gets rid of the portability
> problem and, arguably, makes the view more useful than it is today.
> I think we should define the view as showing, not what was in the config
> file(s) at the last SIGHUP, but what is in the files *now*.  That means
> you could use it to validate edits before you attempt to apply them,
> rather than having to pull the trigger and then ask if it worked.  And yet
> it would remain just about as useful as it is now for post-mortem checks
> when a SIGHUP didn't do what you expected.
>
> This could be implemented by doing essentially a SIGHUP cycle but passing
> changeVal = false to set_config_option.  Other details would remain mostly
> as in my WIP patch of yesterday.  The temporary context for doing SIGHUP
> work still seems like a good idea, but we could flush it at the end of
> the view's execution rather than needing to hang onto it indefinitely.
>
> The main bug risk here is that there might be GUCs whose apply_hook is
> making validity checks that should have been in a check_hook.  However,
> any such coding is wrong already; and the symptom here would only be that
> the view might fail to point out values that can't be applied, which would
> be annoying but it's hardly catastrophic.
>
> Comments?
>

You meant that we parse each GUC parameter in configration file, and
then pass changeVal=false to set_config_option whenever
pg_file_settings is refered.
So this view would be used for checking whether currently
configuration file is applied successfully or not, right?

The such a feature would be also good, but the main purpose of
pg_file_settings was to resolve where each GUC parameter came from,
especially in case of using ALTER SYSTEM command.
I'm not sure that it would be adequate for our originally purpose.

Regards,

--
Sawada Masahiko