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?
regards, tom lane