[pgadmin-hackers] Re: PATCH: RM# 1679 - Background process for "restore" not reportingstatus back to pgAdmin

Поиск
Список
Период
Сортировка
От Ashesh Vashi
Тема [pgadmin-hackers] Re: PATCH: RM# 1679 - Background process for "restore" not reportingstatus back to pgAdmin
Дата
Msg-id CAG7mmozKb39qf-A6mc---yE32CwYALR2NPedTnwx4f2e4vHB=A@mail.gmail.com
обсуждение исходный текст
Ответ на [pgadmin-hackers] Re: PATCH: RM# 1679 - Background process for "restore" not reportingstatus back to pgAdmin  (Dave Page <dpage@pgadmin.org>)
Ответы [pgadmin-hackers] Re: PATCH: RM# 1679 - Background process for "restore" not reportingstatus back to pgAdmin  (Dave Page <dpage@pgadmin.org>)
Список pgadmin-hackers
Hi Dave,

On Mon, Dec 12, 2016 at 4:01 PM, Dave Page <dpage@pgadmin.org> wrote:
Hi,

On Fri, Dec 9, 2016 at 9:16 AM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:
Hi Dave,

Please find the patch to resolve the issue reported in RM #1679

This will take care of:
- Find the appropriate available Python interpreter to execute the process_executor.py.
  In case of WSGI or Runtime, it was not properly find the interpreter required to execute that script. Also, on windows - we should give priority to the windowless python interpreter (if available).
- Execute the process_executor.py script with proper platform dependent flags to run it as daemon.
- Run the process_executor.py in proper daemon mode. It helps to run the long running processes like backup, restore, etc.
  On windows, run the process_executor.py from process_executor.py in detached mode to allow the child process to run in detached mode.
  On POSIX, fork the process_executor.py to allow the child process to run in daemon mode.
  Also - listen the signal like SIGINT, SIGTERM, so that - the child does not kill, or hangup (It used to happen.


NOTE:
This patch does not take care of the unicode errors in the path. I will send a separate patch for the same.

Unfortunately my first test of this failed:

SERVER_MODE = False
Python 2.7.11 (Mac default)
Running in Chrome

I ran a backup of a database, and got the green backup initiated popup... then, nothing. Upon checking my config, I found I had the PostgreSQL Bin Path set to "$DIR/a/b/c", which clearly won't work. So, we're not yet detecting failure to start a process properly.
During exception handling, the logger's encoding was not set properly during initialisation,  that was resulting into an error.

Also - sometime the process execution does not start quickly enough to list down the process execution properly.
Hence - we should check the process list after some time.

Please find the update patch with the above both problems resolved.


--

Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company


http://www.linkedin.com/in/asheshvashi


I then corrected the path to "/Library/PostgreSQL/9.6/bin", and re-ran the backup. That didn't work either - I saw exactly the same result as before, a green popup, then nothing.
 
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Вложения

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

Предыдущее
От: Murtuza Zabuawala
Дата:
Сообщение: [pgadmin-hackers] PATCH: Enhancement in SQL Field Backform control (pgAdmin4)
Следующее
От: Dave Page
Дата:
Сообщение: Re: [pgadmin-hackers] [pgAdmin4][Patch]: RM #1807 Query Tool Does NotRecognize When File Changes Have Been Saved