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-NCd5MHNSPCgr8MFroa479+5s2Kx=nVpq=DCXS5YADp+w@mail.gmail.com
Whole thread Raw
In response to Re: pg_upgrade failure on Windows Server  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: pg_upgrade failure on Windows Server  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-bugs
On Mon, Mar 2, 2015 at 9:42 AM, Michael Paquier <michael.paquier@gmail.com> wrote:
On Thu, Jan 22, 2015 at 4:07 PM, Asif Naeem <anaeem.it@gmail.com> wrote:
> Thank you. I have added it to next commitfest.

Sorry for the late reply.

So I have been looking at both patches, and I would definitely be
useful to authorize the use of restricted tokens for both pg_upgrade
and pg_resetxlog. The patch for pg_resetxlog should be rebased on
latest HEAD because there is a small diff with get_restricted_token()
though.

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? Let's say in
src/common/restricted_token.c or a better name than the one I just
gave out. Then, you could plug-in this new common routine with
pg_upgrade and pg_resetxlog in a second patch.

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.

Regards,
Muhammad Asif Naeem
 
Regards,
--
Michael

Attachment

pgsql-bugs by date:

Previous
From: "Ruth Melendo"
Date:
Subject: Truncate cascade doesn´t work with BDR
Next
From: Jeff Janes
Date:
Subject: Re: Functional indexes with slow functions are misplanned