Re: pg_file_settings view vs. Windows

From: Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, 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 03:15:43
Message-ID: CAD21AoBe00qZW3sTFWf4=5YSFmzb6NGo+Yz-OsAL8wy3xrG3Ag@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jun 28, 2015 at 10:40 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
>> On Sun, Jun 28, 2015 at 8:20 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> 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.
>
> Well, mumble. After playing with this for a bit, I'm fairly convinced
> that it offers useful functionality, especially with the error-reporting
> additions I've proposed. Right now, there is no easy way to tell whether
> a SIGHUP has worked, or why not if not, unless you have access to the
> postmaster log. So I think there's definite usefulness here for
> remote-administration scenarios.
>
> So I kinda think that alternative 1 (document the Windows deficiency)
> is better than having no such functionality at all. Obviously a proper
> fix would be better yet, but that's something that could be rolled in
> later.
>
>> 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?
>
> Agreed, but it was evidently not obvious to anyone that there was a
> portability issue in this code, else we'd have resolved the issue
> before it got committed. As a thought experiment, what would happen
> if we'd not noticed this issue till post-release, which is certainly
> not implausible?
>
> Also, there are multiple pre-existing minor bugs (the leakage problem
> I mentioned earlier, and some other things I've found while hacking
> on the view patch) that we would have to deal with in some other
> way if we revert now. I'd just as soon not detangle that.
>

Thank you for bug report.

I have not came up with portable idea yet, but I will deal with this
problem immediately.
If I couldn't come up with better solution, I'd like to propose #1 idea.
But it would be unavoidable to be revert it if there are any reason
for Windows support.

Regards,

--
Sawada Masahiko

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2015-06-28 03:40:05 Re: Solaris testers wanted for strxfrm() behavior
Previous Message Tom Lane 2015-06-28 02:14:45 Re: Solaris testers wanted for strxfrm() behavior