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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers