Re: pg_upgrade failure on Windows Server - Mailing list pgsql-bugs

From Asif Naeem
Subject Re: pg_upgrade failure on Windows Server
Date
Msg-id CAEB4t-PgQJwN4kjYaQ61d1c_z=FFjVTM4DsrVt6cjwYLQ2DreQ@mail.gmail.com
Whole thread Raw
In response to Re: pg_upgrade failure on Windows Server  (Asif Naeem <anaeem.it@gmail.com>)
Responses Re: pg_upgrade failure on Windows Server
List pgsql-bugs
Thank you for useful suggestions, PFA patch, for pg_ctl.c and pg_regress.c it relies on CreateRestrictedProcess() function now.

src/common/restricted_token.c
     #define write_stderr(fmt, ...) fprintf(stderr, fmt, __VA_ARGS__)

src//bin/pg_ctl/pg_ctl.c
static void
write_stderr(const char *fmt,...)
{
...
/*
* On Win32, we print to stderr if running on a console, or write to
* eventlog if running as a service
*/
if (!isatty(fileno(stderr))) /* Running as a service */
{
...
}
 
src/backend/port/win32/security.c
void
write_stderr(const char *fmt,...)
{
...
/*
* On Win32, we print to stderr if running on a console, or write to
* eventlog if running as a service
*/
if (pgwin32_is_service()) /* Running as a service */
{
...
}
 
security.c write_stderr() implementation seems correct, that relies on pgwin32_is_service() function but it seems little expensive operation to write error messages. pg_ctl.c write_stderr() implementation depend on isatty() to detect if it is running as service, I doubt that if it is right way to to do so. Any suggestion how to tackle this situation, along with this can we make common routine of write_stderr() function that others use it instead of defining their own ?.

Please do let me know if I missed something or more information is required. Thanks.


On Mon, Mar 16, 2015 at 2:07 PM, Asif Naeem <anaeem.it@gmail.com> wrote:
+1

On Fri, Mar 13, 2015 at 4:32 AM, Michael Paquier <michael.paquier@gmail.com> wrote:
On Thu, Mar 12, 2015 at 11:45 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Michael Paquier wrote:
>> On Thu, Mar 12, 2015 at 6:50 AM, Alvaro Herrera
>> <alvherre@2ndquadrant.com> wrote:
>
>> > Is this a backpatchable bug fix, or are we considering this only for the
>> > master branch?
>>
>> It would be good to get that backpatched, that's something we really
>> miss now IMO. Now it modifies libpgcommon, so Windows packagers (me
>> being one) will certainly need to patch a bit stuff but that's a
>> one-line changer so it's not a big deal. And I imagine that this is
>> actually the reason why Asif reported that as a bug as well.
>
> I think it'd be better to patch only pg_upgrade in back branches, so
> that there are no libpgcommon changes.  Seems that would make life
> easier for packagers (See the \connect thread, where Robert opined that
> it'd be better to duplicate some routines in back branches rather than
> refactor libpq code and move the common code to pgcommon.  I didn't
> completely agree with him at the time, but now that you mention
> packagers pain, maybe he has a point.)
>
> So let's do the refactoring in the master branch only, and duplicate
> the code in back branches.  Nasty, but it seems the more robust
> approach.

This plan sounds fine to me.
--
Michael


Attachment

pgsql-bugs by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: BUG #12872: Inconsistent processing of interval values
Next
From: Michael Paquier
Date:
Subject: Re: pg_upgrade failure on Windows Server