> 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.
I'm just wondering why we did not catch this earlier. If this is because threre's no regression test case for pg_file_settings view, we should add along with any of solutions above (of course except #4) IMO. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
