Re: [Patch] - Fix for bug #2558, InitDB failed to run - Mailing list pgsql-patches

From Andrew Dunstan
Subject Re: [Patch] - Fix for bug #2558, InitDB failed to run
Date
Msg-id 44E0ACF8.9060908@dunslane.net
Whole thread Raw
In response to Re: [Patch] - Fix for bug #2558, InitDB failed to run on windows 2003  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: [Patch] - Fix for bug #2558, InitDB failed to run
List pgsql-patches
Alvaro Herrera wrote:
> dror wrote:
>
>
>> There were two options to solve this issue:
>>
>> Create a new file , grant a write permission for the Postgres user
>> and redirect the output to that file. (EnterpriseDB  use this method)
>> Canceling the redirection at all.
>>
>> I choose the second option and omit the redirection in any case that
>> it windows machine and the redirection was sent to DEVNULL.
>>
>> The only files that I changed are: initDB.c, exec.c and pg_ctl.c
>>
>
> Please submit the changes as patches, instead of the whole files.  Also,
> please specify which branch do these patches apply -- is this for 8.1,
> or for the current development code?  When checked against the 8.1
> pg_ctl.c, the file you sent only contains a regression for a bug fix,
> and no change related to what you describe above.
>
> On the other hand, it may be useful to lose the redirection only on the
> cases where it fails, so we still have reasonable behavior on non-broken
> platforms.  Or maybe there's a better solution.
>
>

I am inclined to say we should make it into a runtime test and use a
tmpfile on Windows if the test fails. I am more than somewhat perplexed
as to why the NUL device should be a security risk ... what are they
thinking??

The case that bothers me more is where input is redirected - will that
also work?

cheers

andrew

pgsql-patches by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [Patch] - Fix for bug #2558, InitDB failed to run on windows 2003
Next
From: Tom Lane
Date:
Subject: Re: [Patch] - Fix for bug #2558, InitDB failed to run