Re: pg_upgrade failure on Windows Server

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Asif Naeem <anaeem(dot)it(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: pg_upgrade failure on Windows Server
Date: 2015-03-05 06:37:23
Message-ID: CAB7nPqSK-YDBrszwWCAQH_sgXdO23Ja-LjqpnqbbR=ukm_qj4w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, Mar 4, 2015 at 10:53 PM, Asif Naeem wrote:
> On Mon, Mar 2, 2015 at 9:42 AM, Michael Paquier wrote:
>>
>> The portion for initdb to make it use restricted tokens has been added
>> some time ago with fc9c20e, and the one of pg_ctl with a25cd81, both
>> of them in 2006, so instead of duplicating again the logic for
>> pg_upgrade and pg_resetxlog, shouldn't we create a common routine in
>> src/common and link to it all the frontend binaries that need it?
>> Hence, Asif, could you refactor first the existing code and make it
>> use a new API in libpqcommon?
>
> Sure. PFA patch, restricted token code is moved to
> src/common/restricted_token.c, Now it uses common routine for initdb,
> pg_upgrade and pg_resetxlog. Please do let me know if I missed something or
> more information is required. Thanks.

Thanks. This looks fine to me (tested on MinGW-32 and MSVC). I just
have one comment: get_restricted_token should use progname as
argument. This way you can just keep progname as a static variable for
each frontend and not play with constant variables in both code paths,
aka src/common and src/bin stuff.

Regards,
--
Michael

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message pgriboval 2015-03-05 08:41:09 BUG #12830: postgres-9.4 upgrade is missing PGPORT
Previous Message Jamie Koceniak 2015-03-05 03:55:05 Re: BUG #12050: Orphaned base files