Re: pg_upgrade failure on Windows Server

Поиск
Список
Период
Сортировка
От Asif Naeem
Тема Re: pg_upgrade failure on Windows Server
Дата
Msg-id CAEB4t-NCd5MHNSPCgr8MFroa479+5s2Kx=nVpq=DCXS5YADp+w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_upgrade failure on Windows Server  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: pg_upgrade failure on Windows Server  (Michael Paquier <michael.paquier@gmail.com>)
Список 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

Вложения

В списке pgsql-bugs по дате отправления:

Предыдущее
От: "Ruth Melendo"
Дата:
Сообщение: Truncate cascade doesn´t work with BDR
Следующее
От: Jeff Janes
Дата:
Сообщение: Re: Functional indexes with slow functions are misplanned