> 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
