From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: pg_file_settings view vs. Windows |
Date: | 2015-06-27 23:13:08 |
Message-ID: | 20150628.081308.815671992248599289.t-ishii@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-06-27 23:20:43 | Re: pg_file_settings view vs. Windows |
Previous Message | Jeff Janes | 2015-06-27 22:17:33 | pg_trgm version 1.2 |