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-02 04:42:43
Message-ID: CAB7nPqSdKwtBeSq-TVwP5U4nNqHqfpKdWE1L+=P3Vxcfx820kA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, Jan 22, 2015 at 4:07 PM, Asif Naeem <anaeem(dot)it(at)gmail(dot)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.
Regards,
--
Michael

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2015-03-02 04:44:03 Re: pg_upgrade failure on Windows Server
Previous Message Heikki Linnakangas 2015-03-01 20:32:41 Re: BUG #12799: libpq - SSL pqsecure_read() doesn't clean openssl error queue before reading