Re: pg_file_settings view vs. Windows

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

In response to

Responses

Browse pgsql-hackers by date

  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