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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

In response to


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