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.
This is because before that happens, it's depending on having inherited
the state data from the postmaster via fork(), which of course does not
happen with EXEC_BACKEND. This applies to both the committed version and
my proposed rewrite.
AFAICS the only "correct" fix would be to add the pg_file_settings
state data to the set of data dumped and reloaded through
write_nondefault_variables/read_nondefault_variables. That would add
a fair amount of code, and it might hurt backend startup time more than
the feature is worth. In any case, I'm not volunteering to do it.
More or less bad alternative answers include:
1. Just document the current behavior.
2. On Windows, force a SIGHUP processing cycle if we're asked to execute
the view and we see that no state data exists yet. This would have the
result that the current backend might adopt settings that no other session
has yet, which is not so great but might be tolerable.
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.
4. Revert the pg_file_settings patch altogether until the author comes
up with a more portable implementation.
Thoughts? As I said, I'm not volunteering to fix this.
regards, tom lane
