[pgadmin-hackers] Re: PATCH: RM# 1679 - Background process for "restore" not reportingstatus back to pgAdmin
От | Dave Page |
---|---|
Тема | [pgadmin-hackers] Re: PATCH: RM# 1679 - Background process for "restore" not reportingstatus back to pgAdmin |
Дата | |
Msg-id | CA+OCxowgefk==_mH4bnih=RMS=v5Ouf1HhStOyYB0pvuq-v+Ng@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
|
Список | pgadmin-hackers |
On Mon, Dec 19, 2016 at 11:52 AM, Dave Page <dpage@pgadmin.org> wrote: > > > On Fri, Dec 16, 2016 at 10:16 AM, Ashesh Vashi > <ashesh.vashi@enterprisedb.com> wrote: >> >> 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. > > > Same results with the new patch - either with a correct bin path or an > incorrect one, I see the green notification that the backup has started, > then nothing. > > Sidenote: I don't even see anything at all in the console output. I think we > should at least spit out a debug message showing the command line we're > executing the launcher with, and ideally include any other details we can > such as job IDs etc. BTW; attached is my process table from the SQLite database. I believe the last two rows are from my test today. The out and err logs for both are empty files. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Вложения
В списке pgadmin-hackers по дате отправления: