From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Tatsuo Ishii <ishii(at)postgresql(dot)org>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_file_settings view vs. Windows |
Date: | 2015-06-28 01:19:05 |
Message-ID: | CAB7nPqTnhvoa0miQizjomZ+sQ_+Gt5xK+4LBG_KakXisQJcWAA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Jun 28, 2015 at 8:20 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Tatsuo Ishii <ishii(at)postgresql(dot)org> writes:
>>> 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.
>
>> 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,
>
> Yeah, exactly. Unfortunately I see no way to add a useful test, at least
> not one that will work in installcheck mode. There's no way to predict
> what will be in the view in that case. Even for "make check", the output
> would be pretty darn environment-dependent.
And also because this patch had no review input regarding Windows and
EXEC_BACKEND. I would suggest pinging the author (just did so),
waiting for a fix a bit, and move on with 4. if nothing happens. We
usually require that a patch includes support for Windows as a
requirement (see for example discussions about why pg_fincore in not a
contrib module even if it overlaps a bit with pg_prewarm), why would
this patch have a different treatment?
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-06-28 01:40:56 | Re: pg_file_settings view vs. Windows |
Previous Message | Tatsuo Ishii | 2015-06-28 00:10:39 | Refactoring pgbench.c |