Re: pgagent unicode support
Hi Dave/Ashesh, Do you have any further comments ? Thanks, Neel Patel On Wed, Feb 24, 2021 at 8:14 PM Sergey Burladyan wrote: > Neel Patel writes: > > > Thanks for the review. Please find the attached updated patch. > > Do review it and let me know in case of any comments. > > Looks good, thanks! > > -- > Sergey Burladyan >
Re: pgagent unicode support
Hi Sergey, Thanks for the review. Please find the attached updated patch. Do review it and let me know in case of any comments. Thanks, Neel Patel On Wed, Feb 24, 2021 at 5:12 PM Sergey Burladyan wrote: > Sergey Burladyan writes: > > > Maybe it should look something like this: > > +wcstombs_s(, mbs, mb_len + 1, wchar_str, mb_len); > > Ah, and we missed check for error. > > Something like this, maybe: > +#ifdef __WIN32__ > +size_t charsConverted = 0; > +if (wcstombs_s(, mbs, mb_len + 1, wchar_str, > mb_len) != 0) { > +delete [] mbs; > +return NULL; > +} > +#else > > -- > Sergey Burladyan > pgagent_unicode_v2.patch Description: Binary data
Re: pgagent unicode support
Hi Sergey, Do you have any comments for this updated patch ? Let us know ASAP so that we can commit it. Thanks, Neel Patel On Thu, Feb 18, 2021 at 5:12 PM Neel Patel wrote: > Hi Sergey, > > Thank you for the patch. It looks good to me except below. > > We have modified the patch as we fixed the memory leak ( review comment > given by Ashesh ) and also fixed the compilation warnings. > Can you please review and let us know ? > > Thanks, > Neel Patel > > On Mon, Feb 15, 2021 at 6:15 PM Neel Patel > wrote: > >> Thanks Sergey for the patch. >> >> Sure Dave. >> There is some compilation warning in linux, I will fix those and test >> pgAgent in windows and update the thread. >> >> On Mon, Feb 8, 2021 at 2:55 PM Dave Page wrote: >> >>> Hi >>> >>> On Sat, Feb 6, 2021 at 5:00 AM Sergey Burladyan >>> wrote: >>> >>>> Currently pgagent doesn't handle unicode correctly. >>>> >>>> CharToWString function corrupt multibyte characters because it processes >>>> string one byte at a time: >>>> 148 std::string s = std::string(cstr); >>>> 149 std::wstring wsTmp(s.begin(), s.end()); >>>> >>>> WStringToChar function does not take into account that there can be >>>> _multi_byte character on wcstombs output and create buffer with >>>> size = wcslen: >>>> 157 int wstr_length = wcslen(wchar_str); >>>> 158 char *dst = new char[wstr_length + 10]; >>>> >>>> Also pgagent do not setup locale with setlocale(), without it all >>>> wcs/mbs functions cannot handle multibyte strings. >>>> >>>> For example: >>>> >>>> === step code === >>>> select 'это проверка кириллицы в теле запроса pgagent' >>>> = >>>> >>>> === postgres log === >>>> 2021-02-05 23:19:05 UTC [15600-1] postgres@postgres ERROR: >>>> unterminated quoted string at or near "'" at character 8 >>>> 2021-02-05 23:19:05 UTC [15600-2] postgres@postgres STATEMENT: select >>>> ' >>>> >>>> >>>> Please see attached patch. >>>> I only test it on GNU/Linux and can't test it on Windows, sorry. >>>> >>> >>> Thanks for the patch! Neel/Ashesh; can you take a look please? It looks >>> OK to me, but then I'm not overly familiar with multibyte string handling. >>> What, if anything, needs to be done on Windows? >>> >>> >>> -- >>> Dave Page >>> Blog: http://pgsnake.blogspot.com >>> Twitter: @pgsnake >>> >>> EDB: http://www.enterprisedb.com >>> >>>
Re: pgagent unicode support
Hi Sergey, Thank you for the patch. It looks good to me except below. We have modified the patch as we fixed the memory leak ( review comment given by Ashesh ) and also fixed the compilation warnings. Can you please review and let us know ? Thanks, Neel Patel On Mon, Feb 15, 2021 at 6:15 PM Neel Patel wrote: > Thanks Sergey for the patch. > > Sure Dave. > There is some compilation warning in linux, I will fix those and test > pgAgent in windows and update the thread. > > On Mon, Feb 8, 2021 at 2:55 PM Dave Page wrote: > >> Hi >> >> On Sat, Feb 6, 2021 at 5:00 AM Sergey Burladyan >> wrote: >> >>> Currently pgagent doesn't handle unicode correctly. >>> >>> CharToWString function corrupt multibyte characters because it processes >>> string one byte at a time: >>> 148 std::string s = std::string(cstr); >>> 149 std::wstring wsTmp(s.begin(), s.end()); >>> >>> WStringToChar function does not take into account that there can be >>> _multi_byte character on wcstombs output and create buffer with >>> size = wcslen: >>> 157 int wstr_length = wcslen(wchar_str); >>> 158 char *dst = new char[wstr_length + 10]; >>> >>> Also pgagent do not setup locale with setlocale(), without it all >>> wcs/mbs functions cannot handle multibyte strings. >>> >>> For example: >>> >>> === step code === >>> select 'это проверка кириллицы в теле запроса pgagent' >>> = >>> >>> === postgres log === >>> 2021-02-05 23:19:05 UTC [15600-1] postgres@postgres ERROR: >>> unterminated quoted string at or near "'" at character 8 >>> 2021-02-05 23:19:05 UTC [15600-2] postgres@postgres STATEMENT: select ' >>> >>> >>> Please see attached patch. >>> I only test it on GNU/Linux and can't test it on Windows, sorry. >>> >> >> Thanks for the patch! Neel/Ashesh; can you take a look please? It looks >> OK to me, but then I'm not overly familiar with multibyte string handling. >> What, if anything, needs to be done on Windows? >> >> >> -- >> Dave Page >> Blog: http://pgsnake.blogspot.com >> Twitter: @pgsnake >> >> EDB: http://www.enterprisedb.com >> >> pgagent_unicode.patch Description: Binary data
Re: pgagent unicode support
Thanks Sergey for the patch. Sure Dave. There is some compilation warning in linux, I will fix those and test pgAgent in windows and update the thread. On Mon, Feb 8, 2021 at 2:55 PM Dave Page wrote: > Hi > > On Sat, Feb 6, 2021 at 5:00 AM Sergey Burladyan > wrote: > >> Currently pgagent doesn't handle unicode correctly. >> >> CharToWString function corrupt multibyte characters because it processes >> string one byte at a time: >> 148 std::string s = std::string(cstr); >> 149 std::wstring wsTmp(s.begin(), s.end()); >> >> WStringToChar function does not take into account that there can be >> _multi_byte character on wcstombs output and create buffer with >> size = wcslen: >> 157 int wstr_length = wcslen(wchar_str); >> 158 char *dst = new char[wstr_length + 10]; >> >> Also pgagent do not setup locale with setlocale(), without it all >> wcs/mbs functions cannot handle multibyte strings. >> >> For example: >> >> === step code === >> select 'это проверка кириллицы в теле запроса pgagent' >> = >> >> === postgres log === >> 2021-02-05 23:19:05 UTC [15600-1] postgres@postgres ERROR: unterminated >> quoted string at or near "'" at character 8 >> 2021-02-05 23:19:05 UTC [15600-2] postgres@postgres STATEMENT: select ' >> >> >> Please see attached patch. >> I only test it on GNU/Linux and can't test it on Windows, sorry. >> > > Thanks for the patch! Neel/Ashesh; can you take a look please? It looks OK > to me, but then I'm not overly familiar with multibyte string handling. > What, if anything, needs to be done on Windows? > > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EDB: http://www.enterprisedb.com > >
Re: pgAgent build warnings on Fedora 32
Hi Devrim, I have tried with gcc 10.1 on Ubuntu and I checked the logs but did not find any warning. Below is my setup and logs during pgAgent compilation. Is there any specific gcc 10.X version ? Let me know, I can set up and send a patch. # neel@ubuntu:~/Projects/pgagent/build$ c++ --version c++ (Ubuntu 10.1.0-2ubuntu1~18.04) 10.1.0 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. neel@ubuntu:~/Projects/pgagent/build$ g++ --version g++ (Ubuntu 10.1.0-2ubuntu1~18.04) 10.1.0 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. neel@ubuntu:~/Projects/pgagent/build$ gcc --version gcc (Ubuntu 10.1.0-2ubuntu1~18.04) 10.1.0 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. neel@ubuntu:~/Projects/pgagent/build$ PATH=/opt/PostgreSQL/10/bin:$PATH cmake ../ -DSTATIC_BUILD=NO -DCMAKE_PREFIX_PATH=/home/neel/pgagent_install -- The C compiler identification is GNU 10.1.0 -- The CXX compiler identification is GNU 10.1.0 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Looking for pthread.h -- Looking for pthread.h - found -- Looking for pthread_create -- Looking for pthread_create - not found -- Looking for pthread_create in pthreads -- Looking for pthread_create in pthreads - not found -- Looking for pthread_create in pthread -- Looking for pthread_create in pthread - found -- Found Threads: TRUE -- Boost version: 1.65.1 -- Found the following Boost libraries: -- filesystem -- regex -- date_time -- thread -- system -- chrono -- atomic -- -- -- Configuration summary: -- -- Project : pgagent -- Description : pgAgent is a job scheduling engine for PostgreSQL -- Version : 4.2.0 -- -- PostgreSQL version string : PostgreSQL 10.11 -- PostgreSQL version parts: 10 -- PostgreSQL path : /opt/PostgreSQL/10 -- PostgreSQL config binary: /opt/PostgreSQL/10/bin/pg_config -- PostgreSQL include path : /opt/PostgreSQL/10/include -- PostgreSQL library path : /opt/PostgreSQL/10/lib -- PostgreSQL share path : /opt/PostgreSQL/10/share/postgresql -- -- Boost version : 1.65.1 -- Boost path : /usr/include -- Boost include directory : /usr/include -- Boost library directory : /usr/lib/x86_64-linux-gnu -- Boost Static linking: NO -- -- -- Configuring done -- Generating done -- Build files have been written to: /home/neel/Projects/pgagent/buildneel@ubuntu:~/Projects/pgagent/build$ make Scanning dependencies of target run [ 11%] Generating pgagent--4.2.sql, pgagent.control [ 11%] Built target run Scanning dependencies of target pgagent [ 22%] Building CXX object CMakeFiles/pgagent.dir/connection.cpp.o [ 33%] Building CXX object CMakeFiles/pgagent.dir/job.cpp.o [ 44%] Building CXX object CMakeFiles/pgagent.dir/misc.cpp.o [ 55%] Building CXX object CMakeFiles/pgagent.dir/pgAgent.cpp.o [ 66%] Building CXX object CMakeFiles/pgagent.dir/precomp.cpp.o [ 77%] Building CXX object CMakeFiles/pgagent.dir/unix.cpp.o [ 88%] Building CXX object CMakeFiles/pgagent.dir/win32.cpp.o [100%] Linking CXX executable pgagent [100%] Built target pgagent ### On Wed, Sep 9, 2020 at 7:39 PM Devrim Gündüz wrote: > > Hi Neel, > > On Fri, 2020-04-24 at 18:15 +0530, Neel Patel wrote: > > I will look into it. > > Any updates? > > Cheers, > -- > Devrim Gündüz > Open Source Solution Architect, Red Hat Certified Engineer > Twitter: @DevrimGunduz , @DevrimGunduzTR >
Re: Raise an exception under Python < 3.4
Hi, On Wed, Apr 29, 2020 at 2:52 PM Dave Page wrote: > Hi > > On Wed, Apr 29, 2020 at 10:13 AM Neel Patel > wrote: > >> Hi Dave, >> >> Patch looks good to me except one condition as we do support from Python >> 3.4 onwards. I have modified that condition and attached the updated patch. >> > > What did you change exactly (curious about what I missed)? > Previously it was like, *+if sys.version_info < (3, 3):* *+raise Exception('This application must be run under Python 3.4 or later.')* Modified as below. *+if sys.version_info < (3, 4):* *+raise Exception('This application must be run under Python 3.4 or later.')* > >> >> I have also removed the other references of Python2. Attached is the >> patch. Do review it and let me know for comments. >> > > I think there's a lot more than that - try searching the entire tree for > PY2 or sys.version. This was on my personal todo as a next step, but feel > free to update your patch :-) > Sure. > > Thanks! > > >> >> Thanks, >> Neel Patel >> >> On Mon, Apr 27, 2020 at 9:27 PM Dave Page wrote: >> >>> The attached patch raises an exception if run under Python < 3.4. It >>> also cleans up the README to remove references to Python 2 and removes >>> Python 2-isms from the main config. >>> >>> -- >>> Dave Page >>> Blog: http://pgsnake.blogspot.com >>> Twitter: @pgsnake >>> >>> EnterpriseDB UK: http://www.enterprisedb.com >>> The Enterprise PostgreSQL Company >>> >> > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
Re: Raise an exception under Python < 3.4
Hi Dave, Patch looks good to me except one condition as we do support from Python 3.4 onwards. I have modified that condition and attached the updated patch. I have also removed the other references of Python2. Attached is the patch. Do review it and let me know for comments. Thanks, Neel Patel On Mon, Apr 27, 2020 at 9:27 PM Dave Page wrote: > The attached patch raises an exception if run under Python < 3.4. It also > cleans up the README to remove references to Python 2 and removes Python > 2-isms from the main config. > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > Throw_an_exception_if_run_under_Python__=_3_3,_and_update_the_docs_and_main_config_for_Pyt_v2.patch Description: Binary data Remove_Python2_Reference_Core_files.patch Description: Binary data
Re: Remove Python 2 support from the desktop runtime
Hi Dave, I reviewed and tested and it looks good to me. Thanks, Neel Patel On Tue, Apr 28, 2020 at 1:32 PM Dave Page wrote: > Apparently, yes :-( > > On Mon, Apr 27, 2020 at 9:15 PM Ashesh Vashi < > ashesh.va...@enterprisedb.com> wrote: > >> Did you forget to attach? >> >> — Ashesh >> >> On Mon, 27 Apr 2020 at 21:47, Dave Page wrote: >> >>> Patch for $SUBJECT attached. >>> >>> -- >>> Dave Page >>> Blog: http://pgsnake.blogspot.com >>> Twitter: @pgsnake >>> >>> EnterpriseDB UK: http://www.enterprisedb.com >>> The Enterprise PostgreSQL Company >>> >> -- >> >> -- >> >> Thanks & Regards, >> >> Ashesh Vashi >> EnterpriseDB INDIA: Enterprise PostgreSQL Company >> <http://www.enterprisedb.com> >> >> >> *http://www.linkedin.com/in/asheshvashi* >> <http://www.linkedin.com/in/asheshvashi> >> > > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
Re: pgAgent build warnings on Fedora 32
I will look into it. On Fri, Apr 24, 2020 at 5:51 PM Devrim Gündüz wrote: > > Hi, > > pgAgent throws the warnings below while compiling it on Fedora 32, which > uses GCC 10. Can you please take a look? > > Thanks! Devrim > > === > /usr/bin/make > DESTDIR=/var/lib/pgsql/rpm12/BUILDROOT/pgagent_12-4.0.0-4.f32.x86_64 install > In file included from > /var/lib/pgsql/rpm12/BUILD/pgAgent-4.0.0-Source/include/pgAgent.h:36, > from > /var/lib/pgsql/rpm12/BUILD/pgAgent-4.0.0-Source/connection.cpp:12: > /var/lib/pgsql/rpm12/BUILD/pgAgent-4.0.0-Source/include/connection.h: In > constructor 'DBconn::DBconn(const wstring&)': > /var/lib/pgsql/rpm12/BUILD/pgAgent-4.0.0-Source/include/connection.h:117:19: > warning: 'DBconn::m_inUse' will be initialized after [-Wreorder] > 117 | bool m_inUse; > | ^~~ > /var/lib/pgsql/rpm12/BUILD/pgAgent-4.0.0-Source/include/connection.h:113:19: > warning: 'DBconn* DBconn::m_next' [-Wreorder] > 113 | DBconn *m_next; > | ^~ > /var/lib/pgsql/rpm12/BUILD/pgAgent-4.0.0-Source/connection.cpp:21:1: > warning: when initialized here [-Wreorder] >21 | DBconn::DBconn(const std::wstring ) > | ^~ > In file included from > /var/lib/pgsql/rpm12/BUILD/pgAgent-4.0.0-Source/include/pgAgent.h:36, > from > /var/lib/pgsql/rpm12/BUILD/pgAgent-4.0.0-Source/connection.cpp:12: > /var/lib/pgsql/rpm12/BUILD/pgAgent-4.0.0-Source/include/connection.h:114:19: > warning: 'DBconn::m_prev' will be initialized after [-Wreorder] > 114 | DBconn *m_prev; > | ^~ > /var/lib/pgsql/rpm12/BUILD/pgAgent-4.0.0-Source/include/connection.h:102:19: > warning: 'int DBconn::m_minorVersion' [-Wreorder] > 102 | int m_minorVersion, > | ^~ > /var/lib/pgsql/rpm12/BUILD/pgAgent-4.0.0-Source/connection.cpp:21:1: > warning: when initialized here [-Wreorder] >21 | DBconn::DBconn(const std::wstring ) > | ^~ > /var/lib/pgsql/rpm12/BUILD/pgAgent-4.0.0-Source/connection.cpp: In member > function 'std::wstring DBconn::ExecuteScalar(const wstring&)': > /var/lib/pgsql/rpm12/BUILD/pgAgent-4.0.0-Source/connection.cpp:333:6: > warning: variable 'rows' set but not used [-Wunused-but-set-variable] > 333 | int rows = -1; > | ^~~~ > /var/lib/pgsql/rpm12/BUILD/pgAgent-4.0.0-Source/job.cpp: In member > function 'int Job::Execute()': > /var/lib/pgsql/rpm12/BUILD/pgAgent-4.0.0-Source/job.cpp:157:9: warning: > unused variable 'last_n_char' [-Wunused-variable] > 157 | int last_n_char = 7; > | ^~~ > > -- > Devrim Gündüz > Open Source Solution Architect, Red Hat Certified Engineer > Twitter: @DevrimGunduz , @DevrimGunduzTR >
Re: [pgagent]: Modified 'next_schedule' function and updated pgagent 4.2 version
Hi Dave, On Fri, Apr 24, 2020 at 3:00 PM Dave Page wrote: > > > On Fri, Apr 24, 2020 at 10:23 AM Vik Fearing > wrote: > >> >> >> On Fri, Apr 24, 2020 at 11:10 AM Dave Page wrote: >> >>> Hi >>> >>> On Thu, Apr 23, 2020 at 12:21 PM Neel Patel >>> wrote: >>> >>>> Hi, >>>> >>>> Please find an updated patch that fixes a bug in 'next_schedule' >>>> function where minute should be extracted instead of year for calculation. >>>> >>>> Issue found by: Vik Fearing >>>> >>>> Please find the attached patch that fixed the issue in respective >>>> pgagent files and updated pgagent for 4.2 version. >>>> >>>> Do review it and let me know for comments. >>>> >>> >>> Any reason not to use the rewritten version of the function that Vik >>> wrote? It updated it to use much more modern features of pl/pgsql, rather >>> than the now 15 year old syntax that's currently used. >>> >>> >> >> Well, the current version has received 15 years of testing (despite the >> bug I found), and my rewrite has only received some local testing by me. I >> would like to see my version eventually integrated, but I don't think it >> should be rushed in. >> > > Good point - patch applied, thanks. > > Neel, can you work with the team to do some testing of the function > rewrite as a spare-time project please? > Sure. > > Thanks! > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
[pgagent]: Modified 'next_schedule' function and updated pgagent 4.2 version
Hi, Please find an updated patch that fixes a bug in 'next_schedule' function where minute should be extracted instead of year for calculation. Issue found by: Vik Fearing Please find the attached patch that fixed the issue in respective pgagent files and updated pgagent for 4.2 version. Do review it and let me know for comments. Thanks, Neel Patel pgagent_4_2.patch Description: Binary data
Re: [Patch][pgAdmin4]: Fix pgagent issues
Hi Akshay, Please find the attached update patch with the fix. Also fixed the Roles resql test cases as it was failing due to timezone change. Thanks, Neel Patel On Tue, Apr 21, 2020 at 12:32 PM Akshay Joshi wrote: > Hi Neel > > RESQL test cases are failing on my machine due to different timezone > > - '2020-04-14 01:11:31-07'::timestamp with time zone, '2020-04-15 > 01:11:34-07'::timestamp with time zone, > ? - ^^ ^ - ^ >^ ^ > + '2020-04-14 13:41:31+05:30'::timestamp with time zone, '2020-04-15 > 13:41:34+05:30'::timestamp with time zone, > ? + ^^ > + ^^ > > Please fix the above issue and resend the patch. > > On Mon, Apr 20, 2020 at 3:07 PM Neel Patel > wrote: > >> Hi, >> >> Please find the attached patch to stabilize the pgagent and fix below >> issues. >> >>- Reverse engineering SQL and MSQL was incorrect when the user added >>a job schedule with exception Fixes #5356 >>- Job schedule exception time was not showing correctly in SQL tab. >>- Identify the job step and schedule if disabled from browser tree, >>same as pgagent job - Fixes #4636 >>- Add RE-SQL/MSQL test cases for pgAgent Jobs - Fixes #4623 >> >> Do review it and let me know for comments. >> >> Thanks, >> Neel Patel >> > > > -- > *Thanks & Regards* > *Akshay Joshi* > > *Sr. Software Architect* > *EnterpriseDB Software India Private Limited* > *Mobile: +91 976-788-8246* > diff --git a/web/pgadmin/browser/server_groups/servers/pgagent/__init__.py b/web/pgadmin/browser/server_groups/servers/pgagent/__init__.py index 797a6cb..ee87a1a 100644 --- a/web/pgadmin/browser/server_groups/servers/pgagent/__init__.py +++ b/web/pgadmin/browser/server_groups/servers/pgagent/__init__.py @@ -10,6 +10,7 @@ """Implements the pgAgent Jobs Node""" from functools import wraps import json +from datetime import datetime, time from flask import render_template, request, jsonify from flask_babelex import gettext as _ @@ -323,7 +324,8 @@ SELECT EXISTS( row['jobid'], sid, row['jobname'], -icon="icon-pga_job" +icon="icon-pga_job" if row['jobenabled'] +else "icon-pga_job-disabled" ) ) @@ -500,6 +502,10 @@ SELECT EXISTS( if schedule['jexid']: idx = 0 for exc in schedule['jexid']: +# Convert datetime.time object to string +if isinstance(schedule['jextime'][idx], time): +schedule['jextime'][idx] = \ +schedule['jextime'][idx].strftime("%H:%M:%S") schedule['jscexceptions'].append({ 'jexid': exc, 'jexdate': schedule['jexdate'][idx], diff --git a/web/pgadmin/browser/server_groups/servers/pgagent/schedules/__init__.py b/web/pgadmin/browser/server_groups/servers/pgagent/schedules/__init__.py index ad3e7e9..13bd25a 100644 --- a/web/pgadmin/browser/server_groups/servers/pgagent/schedules/__init__.py +++ b/web/pgadmin/browser/server_groups/servers/pgagent/schedules/__init__.py @@ -74,6 +74,23 @@ class JobScheduleModule(CollectionNodeModule): return 'pga_job' @property +def csssnippets(self): +""" +Returns a snippet of css to include in the page +""" +snippets = [ +render_template( +"pga_schedule/css/pga_schedule.css", +node_type=self.node_type +) +] + +for submodule in self.submodules: +snippets.extend(submodule.csssnippets) + +return snippets + +@property def module_use_template_javascript(self): """ Returns whether Jinja2 template is used for generating the javascript @@ -245,7 +262,8 @@ class JobScheduleView(PGChildNodeView): row['jscid'], row['jscjobid'], row['jscname'], -icon="icon-pga_schedule", +icon="icon-pga_schedule" if row['jscenabled'] else +"icon-pga_schedule-disabled", enabled=row['jscenabled'] ) ) @@ -256,7 +274,8 @@ class JobScheduleView(PGChildNodeView): row['jscid'], row['jscjobid'], row['jscname'], -icon="icon-pga_schedule", +icon="icon-pga_schedule" if row['jscenabled'] else +
[Patch][pgAdmin4]: Fix pgagent issues
Hi, Please find the attached patch to stabilize the pgagent and fix below issues. - Reverse engineering SQL and MSQL was incorrect when the user added a job schedule with exception Fixes #5356 - Job schedule exception time was not showing correctly in SQL tab. - Identify the job step and schedule if disabled from browser tree, same as pgagent job - Fixes #4636 - Add RE-SQL/MSQL test cases for pgAgent Jobs - Fixes #4623 Do review it and let me know for comments. Thanks, Neel Patel diff --git a/docs/en_US/release_notes_4_21.rst b/docs/en_US/release_notes_4_21.rst index d2a42eb..9f152ee 100644 --- a/docs/en_US/release_notes_4_21.rst +++ b/docs/en_US/release_notes_4_21.rst @@ -11,6 +11,7 @@ New features | `Issue #2172 <https://redmine.postgresql.org/issues/2172>`_ - Added search object functionality. | `Issue #2186 <https://redmine.postgresql.org/issues/2186>`_ - Added LDAP authentication support. +| `Issue #4636 <https://redmine.postgresql.org/issues/4636>`_ - Added job step and job schedule disable icons to identify it quickly within browser tree. | `Issue #5181 <https://redmine.postgresql.org/issues/5181>`_ - Added support for parameter toast_tuple_target and parallel_workers of the table. | `Issue #5263 <https://redmine.postgresql.org/issues/5263>`_ - Added support of Foreign Tables to the Schema Diff. | `Issue #5264 <https://redmine.postgresql.org/issues/5264>`_ - Added support of Packages, Sequences and Synonyms to the Schema Diff. @@ -21,6 +22,7 @@ Housekeeping | `Issue #4620 <https://redmine.postgresql.org/issues/4620>`_ - Add Reverse Engineered and Modified SQL tests for procedures. +| `Issue #4623 <https://redmine.postgresql.org/issues/4623>`_ - Add Reverse Engineered and Modified SQL tests for pgagent jobs. Bug fixes * @@ -57,6 +59,7 @@ Bug fixes | `Issue #5302 <https://redmine.postgresql.org/issues/5302>`_ - Fixed an issue where difference SQL is not seen in the schema diff tool for Types. | `Issue #5314 <https://redmine.postgresql.org/issues/5314>`_ - Ensure that switch cell is in sync with switch control for accessibility. | `Issue #5351 <https://redmine.postgresql.org/issues/5351>`_ - Fixed compilation warnings while building pgAdmin. +| `Issue #5356 <https://redmine.postgresql.org/issues/5356>`_ - Fixed msql creation issue while adding exception in pgaagent job schedule. | `Issue #5361 <https://redmine.postgresql.org/issues/5361>`_ - Fixes an issue where pgAdmin4 GUI does not display properly in IE 11. | `Issue #5362 <https://redmine.postgresql.org/issues/5362>`_ - Fixed an issue where the identical packages and sequences visible as different in the schema diff tool. | `Issue #5366 <https://redmine.postgresql.org/issues/5366>`_ - Added alert message to Reset Layout if any of the panels from Query Tool failed to load. @@ -66,4 +69,4 @@ Bug fixes | `Issue #5387 <https://redmine.postgresql.org/issues/5387>`_ - Fixed an issue where the mode is not shown in the properties dialog of functions/procedures if all the arguments are "IN" arguments. | `Issue #5400 <https://redmine.postgresql.org/issues/5400>`_ - Fixed internal server error when the database server is logged in with non-super user. | `Issue #5409 <https://redmine.postgresql.org/issues/5409>`_ - Fixed validation issue in Synonyms node. -| `Issue #5410 <https://redmine.postgresql.org/issues/5410>`_ - Fixed an issue while removing the package body showing wrong modified SQL. \ No newline at end of file +| `Issue #5410 <https://redmine.postgresql.org/issues/5410>`_ - Fixed an issue while removing the package body showing wrong modified SQL. diff --git a/web/pgadmin/browser/server_groups/servers/pgagent/__init__.py b/web/pgadmin/browser/server_groups/servers/pgagent/__init__.py index 797a6cb..ee87a1a 100644 --- a/web/pgadmin/browser/server_groups/servers/pgagent/__init__.py +++ b/web/pgadmin/browser/server_groups/servers/pgagent/__init__.py @@ -10,6 +10,7 @@ """Implements the pgAgent Jobs Node""" from functools import wraps import json +from datetime import datetime, time from flask import render_template, request, jsonify from flask_babelex import gettext as _ @@ -323,7 +324,8 @@ SELECT EXISTS( row['jobid'], sid, row['jobname'], -icon="icon-pga_job" +icon="icon-pga_job" if row['jobenabled'] +else "icon-pga_job-disabled" ) ) @@ -500,6 +502,10 @@ SELECT EXISTS( if schedule['jexid']: idx = 0 for exc in schedule['jexid']: +# Convert datetime.time object to string +if isinstance(schedule['jextime'][idx], time): +schedul
Re: [pgAdmin][RM5210] pgAdmin4 silently truncates text larger than underlying field size
Hi, I think we should remove the type cast from query during update and whatever error is thrown should be shown to UI as per scenario 3. Thanks, Neel Patel On Wed, Apr 15, 2020 at 3:06 PM Khushboo Vashi < khushboo.va...@enterprisedb.com> wrote: > > > On Wed, Apr 15, 2020 at 2:48 PM navnath gadakh < > navnath.gad...@enterprisedb.com> wrote: > >> Hello Hackers, >> >> >> On Tue, Apr 14, 2020 at 5:14 PM Khushboo Vashi < >> khushboo.va...@enterprisedb.com> wrote: >> >>> Hi Navnath, >>> >>> You have compared the column's internal size with the length of the >>> value given by the user. >>> For example, column having integer would have internal size 4 and if I >>> give the value 12121 which is the correct input for the field will fail >>> here because as per your logic column internal size (4) < len(value) (5). >>> >>> I think this implementation is not correct here. >>> >> Yes, my implementations might be wrong. >> >> Below are some important findings on the parameterised query(as we are >> using Jinja templates for building SQL queries). >> Here I have created a table 'account' with some records in it. >> CREATE TABLE public.account >> ( >> user_id integer NOT NULL, >> username character varying(5) >> ) >> >> psycopg2 throws a proper error if I pass username value greater than the >> length of the data type(5) >> Now, I want to pass username value greater than data type length (5) >> >> Scenario 1: Query with data type and length >> >> import psycopg2 >> try: >> conn = psycopg2.connect("dbname='postgres' user='postgres' >> host='XXX.XXX.XXX.XXX' password='test' port=5432") >> cur = conn.cursor() >> cur.execute("UPDATE public.account SET username = >> %(username)s::character varying(5) WHERE user_id = 1;", {"username": >> "username-test-123"}) >> cur.execute("COMMIT;") >> except Exception as e: >> print('Exception : {0}'.format(e)) >> >> *Output:* >> >> It will save the record with 5 char data without any error. >> >> *psql output:* >> >> postgres=# select * from public.account; >> user_id | username >> -+-- >>1 | usern >> (1 row) >> >> Scenario 2: Query with only data type >> >> import psycopg2 >> try: >> conn = psycopg2.connect("dbname='postgres' user='postgres' >> host='XXX.XXX.XXX.XXX' password='test' port=5432") >> cur = conn.cursor() >> cur.execute("UPDATE public.account SET username = >> %(username)s::character varying WHERE user_id = 1;", {"username": >> "username-test-123"}) >> cur.execute("COMMIT;") >> except Exception as e: >> print('Exception : {0}'.format(e)) >> >> *Output:* >> >> Exception : value too long for type character varying(5) >> >> data will not save in the table. >> >> We can consider scenario 2 as it will throw the valid exception and also > typecast the value in the proper format. > >> Scenario 3: Query without data type >> >> import psycopg2 >> try: >> conn = psycopg2.connect("dbname='postgres' user='postgres' >> host='XXX.XXX.XXX.XXX' password='test' port=5432") >> cur = conn.cursor() >> cur.execute("UPDATE public.account SET username = %(username)s WHERE >> user_id = 1;", {"username": "username-test-123"}) >> cur.execute("COMMIT;") >> except Exception as e: >> print('Exception : {0}'.format(e)) >> >> *Output:* >> >> Exception : value too long for type character varying(5) >> >> again data will not save in the table. >> >> These are some different behaviours with psycopg2. So to complete this patch >> which apporach should I follow? or any new approach is also welcome. >> >> Thanks! >> >> >> >>> >>> Thanks, >>> Khushboo >>> >>> >>> >>> On Tue, Apr 14, 2020 at 4:33 PM navnath gadakh < >>> navnath.gad...@enterprisedb.com> wrote: >>> >>>> Hello Hackers, >>>> Please find the attached patch for below fixes: >>>> >>>> - Added validation for table row data that should not be larger >>>> than the field size. >>>> - Rearrange the existing functions to add validation. >>>> - Added test cases. >>>> >>>> Regards, >>>> Navnath Gadakh >>>> >>>> >> >> -- >> Regards, >> Navnath Gadakh >> >
Re: Proposal: Drop support for Internet Explorer
Hi Dave, Looks like patch is missing in attachment. Thanks, Neel Patel On Tue 14 Apr, 2020, 6:53 PM Dave Page, wrote: > Here's an updated patch that gives a slightly different message if the > browser is unknown vs. unsupported/deprecated. As with the previous patch, > the check can be disabled in the config. > > On Fri, Apr 10, 2020 at 5:07 AM Khushboo Vashi < > khushboo.va...@enterprisedb.com> wrote: > >> >> >> On Thu, Apr 9, 2020 at 11:57 PM Darren Duncan >> wrote: >> >>> The patch looks good as much as I understand it, but this raises an >>> important >>> question: >>> >>> How should one best handle minority browsers that may be completely >>> modern but >>> you may not specifically know about them? Such as the newer crop of >>> browsers >>> that emphasize stronger privacy or may have fewer identifiers? >>> >>> While going on a whitelist as the patch essentially does for known good >>> browsers >>> is conservative, I feel that an alteration would be good. >>> >>> I propose dividing the browsers/environments into 3 categories, which >>> are >>> recognized-supported, recognized-unsupported, and unrecognized. >>> >> >>> So the unsupported older versions of supported browsers get a stronger >>> message >>> encouraging a browser switch as they are recognized as unsupported, >>> while >>> unrecognized browsers get a different weaker message saying they weren't >>> recognized so we can't determine if they'd work; both can point to the >>> list of >>> known supported browsers. >>> >>> I do agree with this suggestion. >> >> >>> Related to this, there could be an application toggle that affects the >>> unrecognized category where users can basically say, yes I understand >>> you don't >>> recognize this browser, please hide the warning, or something like that. >>> >>> Also, it probably goes without saying, but the code/templates will need >>> to be >>> structured in such a way that the warning message uses about plain as >>> possible >>> HTML so that if the browser doesn't support displaying the UI in general >>> it can >>> at least display the message. >>> >>> -- Darren Duncan >>> >>> On 2020-04-09 4:36 a.m., Dave Page wrote: >>> > Hi >>> > >>> > On Thu, Apr 9, 2020 at 12:26 AM Darren Duncan wrote: >>> > >>> > If its hard to know how many people are actually using Internet >>> Explorer: >>> > >>> > You could make the next release of pgAdmin display a message >>> occasionally to >>> > users of Internet Explorer saying that Internet Explorer will no >>> longer be >>> > officially supported in a future version, and when that version >>> comes the >>> > message says now no longer supported. >>> > >>> > You can then see how many people contact you about this to express >>> concern. >>> > >>> > >>> > Good idea. I've hacked up a patch to warn users if they're using a >>> deprecated or >>> > unsupported browser. >>> > >>> > CCing Akshay for a review :-) >>> > >>> > -- >>> > Dave Page >>> > Blog: http://pgsnake.blogspot.com >>> > Twitter: @pgsnake >>> > >>> > EnterpriseDB UK: http://www.enterprisedb.com >>> > The Enterprise PostgreSQL Company >>> >>> >>> >>> > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
[Patch]: Typo in 'test_config.json.in' file
Hi, Fix the typo in the test configuration json file while running the test cases. Currently if someone uses the latest file to run the test cases, it will fail to run. Please find the attached patch. Thanks, Neel Patel test_config.patch Description: Binary data
[pgAdmin4][Runtime][Patch]: RM-4864 - Window too small for text in configuration
Hi, Please find an attached patch to fix the issue in the configuration window in runtime where control where not auto resize and visible when the user resizes the dialog. Do review it and let me know for comments. Thanks, Neel Patel diff --git a/runtime/ConfigWindow.ui b/runtime/ConfigWindow.ui index fbdddfc2d..12770160a 100644 --- a/runtime/ConfigWindow.ui +++ b/runtime/ConfigWindow.ui @@ -6,7 +6,7 @@ 0 0 -731 +975 398 @@ -18,7 +18,7 @@ -625 +975 300 @@ -51,7 +51,7 @@ - 589 + 16777215 16777215 @@ -61,6 +61,9 @@ true + +4 + @@ -123,6 +126,9 @@ Qt::Vertical + +QSizePolicy::Fixed + 20 @@ -249,6 +255,9 @@ Qt::Vertical + +QSizePolicy::Fixed + 20 @@ -304,6 +313,19 @@ + + + +Qt::Vertical + + + + 20 + 40 + + + + @@ -312,21 +334,11 @@ Python - - - + + + - - -The options below are intended for expert users only, and may not behave as expected as they modify fixed search paths and are not alternate values. Modify with care! - - -true - - - - - + Qt::Vertical @@ -336,89 +348,240 @@ 20 - 5 + 13 - - - - - Qt::Vertical - - - QSizePolicy::Expanding + + + + + + 0 + 0 + - + - 20 - 60 + 450 + 28 - - - - - - Python Path - - - - - - Enter the path to the directory containing pgAdmin.py if desired. + The options below are intended for expert users only, and may not behave as expected as they modify fixed search paths and are not alternate values. Modify with care! - - - - - - /usr/pgadmin4/lib/python2.7;/usr/pgadmin4/lib/python2.7/site-packages + + true - - - - /usr/pgadmin4/web - - + + + + + +Qt::Vertical + + +QSizePolicy::Fixed + + + + 17 + 13 + + + + + + + + + + + + + 50 + 20 + + + +Qt::LeftToRight + + +Python Path + + +true + + +0 + + + + + + +Qt::Vertical + + +QSizePolicy::Fixed + + + + 20 + 40 + + + + + - - - - Application Path - - + + + + + +/usr/pgadmin4/lib/python2.7;/usr/pgadmin4/lib/python2.7/site-packages + + + + + + + + 0 + 0 + + + + + 300 + 20 + + + +Enter
Re: PgAgent leap year problem
Hi Ashesh, I have reviewed it and looks good. I have updated the sql version in header of each sql file. Thanks, Neel Patel On Wed, Mar 4, 2020 at 12:22 PM Ashesh Vashi wrote: > On Wed, Mar 4, 2020 at 10:53 AM Neel Patel > wrote: > >> Hi Mehmet, >> >> It was a bug in pgAgent. Thank you for sharing the patch. I have reviewed >> and tested, it is working fine. >> >> Dave/Ashesh:- Can we commit this patch ? >> > Mehmet, > > Thanks for your patch. > Changes look good except it does not take care of the upgrade scenarios. > > Hence - updated the patch for the same. > > Neel, > > Would you please review the updated patch with the upgrade scenarios? > > > -- Thanks, Ashesh > >> >> Thanks, >> Neel Patel >> >> On Mon, Mar 2, 2020 at 5:26 PM Mehmet Emin KARAKAŞ >> wrote: >> >>> Hi, >>> >>> Scheduled tasks set as the last day of February this year did not work. >>> In your schedule function have a small bug. Leap year function get year >>> parameter, but your code is sending day as a parameter. Fixing patch >>> attached in this mail. >>> >>> Best Regards... >>> >>> -- >>> MEHMET EMİN KARAKAŞ >>> PostgreSQL DBA >>> >>> Turksat Satellite Communication and Cable TV Operations >>> Konya Yolu 40. Km. 06839 Golbasi / ANKARA - TÜRKİYE >>> Tel : +90 312 615 32 73 >>> Faks : +90 312 615 32 77 >>> >> pgagent_leap_year_v2.patch Description: Binary data
Re: PgAgent leap year problem
Hi Mehmet, It was a bug in pgAgent. Thank you for sharing the patch. I have reviewed and tested, it is working fine. Dave/Ashesh:- Can we commit this patch ? Thanks, Neel Patel On Mon, Mar 2, 2020 at 5:26 PM Mehmet Emin KARAKAŞ wrote: > Hi, > > Scheduled tasks set as the last day of February this year did not work. In > your schedule function have a small bug. Leap year function get year > parameter, but your code is sending day as a parameter. Fixing patch > attached in this mail. > > Best Regards... > > -- > MEHMET EMİN KARAKAŞ > PostgreSQL DBA > > Turksat Satellite Communication and Cable TV Operations > Konya Yolu 40. Km. 06839 Golbasi / ANKARA - TÜRKİYE > Tel : +90 312 615 32 73 > Faks : +90 312 615 32 77 >
Re: RM5049 Patch
Patch only covers removal of the code and change in "coveragerc.in". I guess you missed to add the new files in the patch. Can you please verify ? Thanks, Neel Patel On Wed, Jan 15, 2020 at 1:16 PM Yogesh Mahajan < yogesh.maha...@enterprisedb.com> wrote: > Hi, > > Please find attached patch for api tests for cast node.This covers - > Added new file (cast_test_cases.json) storing inventory, test, expected > data. > Also covers test cases for all cast node related api, > This increase code coverage for cast from 33% to 68%. > > Command to run tests - > --pkg browser.server_groups.servers.databases.casts.tests > > Thanks, > Yogesh Mahajan > QA - Team > EnterpriseDB Corporation > > Phone: +91-9741705709 >
Re: RM 4463 - MSQL test cases for domain node
Hi, Please find attached updated patch. I have tested with PG 9.4, PG 10 & EPAS 10. Do review it and let me know in case of any failures. Thanks, Neel Patel On Fri, Aug 23, 2019 at 1:52 PM Dave Page wrote: > Hi > > On Wed, Aug 21, 2019 at 8:58 AM Neel Patel > wrote: > >> Hi, >> >> Please find attached patch that will add more resql test cases and msql >> test cases for domain node. >> >>- Covered test cases for Length, Precision and Collation. >>- Also added msql test cases. >> >> While writing resql test cases for domain node, I found one more issue >> RM-4644 <https://redmine.postgresql.org/issues/4644>. I have sent >> separate patch for the same. >> > > I'm getting the following error with this patch: > > == > ERROR: runTest > (regression.re_sql.tests.test_resql.ReverseEngineeredSQLTestCases) > Reverse Engineered SQL Test Cases > -- > Traceback (most recent call last): > File > "/Users/dpage/git/pgadmin4/web/regression/re_sql/tests/test_resql.py", line > 126, in runTest > self.execute_test_case(scenarios) > File > "/Users/dpage/git/pgadmin4/web/regression/re_sql/tests/test_resql.py", line > 204, in execute_test_case > if not self.check_msql(scenario, object_id): > File > "/Users/dpage/git/pgadmin4/web/regression/re_sql/tests/test_resql.py", line > 329, in check_msql > object_id) > File > "/Users/dpage/git/pgadmin4/web/regression/re_sql/tests/test_resql.py", line > 178, in get_url > object_url = url_for(rule.endpoint, **options) > File > "/Users/dpage/.virtualenvs/pgadmin4/lib/python3.7/site-packages/flask/helpers.py", > line 356, in url_for > return appctx.app.handle_url_build_error(error, endpoint, values) > File > "/Users/dpage/.virtualenvs/pgadmin4/lib/python3.7/site-packages/flask/app.py", > line 2061, in handle_url_build_error > reraise(exc_type, exc_value, tb) > File > "/Users/dpage/.virtualenvs/pgadmin4/lib/python3.7/site-packages/flask/_compat.py", > line 35, in reraise > raise value > File > "/Users/dpage/.virtualenvs/pgadmin4/lib/python3.7/site-packages/flask/helpers.py", > line 345, in url_for > force_external=external) > File > "/Users/dpage/.virtualenvs/pgadmin4/lib/python3.7/site-packages/werkzeug/routing.py", > line 1776, in build > raise BuildError(endpoint, values, method, self) > werkzeug.routing.BuildError: Could not build url for endpoint > 'NODE-domain.msql_id' with values ['did', 'gid', 'scid', 'sid']. Did you > forget to specify values ['doid']? > > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > RM_4463_V3.patch Description: Binary data
Re: RM 4463 - RESQL test cases for domain node
Hi, Please find attached patch that will add more resql test cases for domain node. - Covered test cases for Length, Precision and Collation. - Also added msql test cases. While writing resql test cases for domain node, I found one more issue RM-4644 <https://redmine.postgresql.org/issues/4644>. I am sending separate patch for the same. Thanks, Neel Patel On Fri, Jul 12, 2019 at 7:10 PM Dave Page wrote: > Thanks, applied. > > On Fri, Jul 12, 2019 at 12:31 PM Neel Patel > wrote: > >> Hi, >> >> Please find attached patch for reverse engineering test cases for domain >> node ( RM #4463 ) >> Do review it and let me know for comments. >> >> Thanks, >> Neel Patel >> > > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > RM_4463_v2.patch Description: Binary data
RM 4463 - MSQL test cases for domain node
Hi, Please find attached patch that will add more resql test cases and msql test cases for domain node. - Covered test cases for Length, Precision and Collation. - Also added msql test cases. While writing resql test cases for domain node, I found one more issue RM-4644 <https://redmine.postgresql.org/issues/4644>. I have sent separate patch for the same. Thanks, Neel Patel RM_4463_v2.patch Description: Binary data
[Patch]: RM-4644 - Length and Precision control for domain node
Hi, Please find attached patch to fix RM-4644 - Length and Precision control should enable/disable based on change in data type. Do review it and let me know for comment. Thanks, Neel Patel RM-4644.patch Description: Binary data
RM 4463 - RESQL test cases for domain node
Hi, Please find attached patch for reverse engineering test cases for domain node ( RM #4463 ) Do review it and let me know for comments. Thanks, Neel Patel RM_4463.patch Description: Binary data
Re: Minor patch to fix reggression of select2 option
Hi Dave, RM is 4218 <https://redmine.postgresql.org/issues/4218> Thanks, Neel Patel On Tue, Apr 30, 2019 at 1:25 PM Dave Page wrote: > Hi > > What's the RM for this? > > On Tue, Apr 30, 2019 at 8:00 AM Neel Patel > wrote: > >> Hi Team, >> >> Please find attached patch to fix the issue where we should properly >> assigned 'dropdownParent' select2 options. >> >> This was regression of commit 6016a5ee989a8f3f56c4a03994eb57989c3c0717 >> >> Do review it and let us know for comments. >> >> Thanks, >> Neel Patel >> > > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
[Patch]: Minor change in dependency_inventory file to generate library file
Hi, Please find attached patch to handle JSON object properly to avoid error like "the JSON object must be str, not 'bytes'" while generating library.txt file. Verified with both python2 and python3. Do review it and let me know for comments. Thanks, Neel Patel -- <https://postgresvision.com/> <https://postgresvision.com/> dependency_inventory_decode.patch Description: Binary data
Re: pgAdmin 3.0 builds
Hi, On Tue, Apr 10, 2018 at 5:44 PM, Dave Pagewrote: > > > On Tue, Apr 10, 2018 at 1:02 PM, Fahar Abbas > wrote: > >> Yes Akshay is not able to reproduce this issue on VMWare Fusion 6.0.6 >> while Khushboo is facing same issue on Windows 07 64. >> >> I am using VMware Fusion 10 version and facing issue on Windows 2012 and >> Windows 07 64 bit. >> > > I also cannot reproduce it in Windows 10, Windows 7 or Windows 2008r2 on > VMware Fusion 8.5.10. > > Can anyone else test on Windows please? > Working fine on my windows 10. > >> >> Kindly suggest, how i can proceed further on this, should we document >> this? >> > > Ignore it for now. I'm far from convinced that it's not something odd with > your VMs. > > >> >> >> >> On Tue, Apr 10, 2018 at 4:55 PM, Dave Page wrote: >> >>> >>> >>> On Tue, Apr 10, 2018 at 12:54 PM, Fahar Abbas < >>> fahar.ab...@enterprisedb.com> wrote: >>> Hi Dave, I am still able to reproduce pgadmin4 crash issue on Windows 07 64 and Windows 2012 R2 64 on fresh VMs: https://redmine.postgresql.org/issues/3227 >>> >>> Did you ever correlate it to VMware versions as I asked last week? >>> >>> -- >>> Dave Page >>> Blog: http://pgsnake.blogspot.com >>> Twitter: @pgsnake >>> >>> EnterpriseDB UK: http://www.enterprisedb.com >>> The Enterprise PostgreSQL Company >>> >> >> >> >> -- >> Fahar Abbas >> QMG >> EnterpriseDB Corporation >> Phone Office: +92-51-835-8874 >> Phone Direct: +92-51-8466803 >> Mobile: +92-333-5409707 >> Skype ID: syed.fahar.abbas >> Website: www.enterprisedb.com >> > > > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
Re: Building releases...
On Mon, Apr 9, 2018 at 6:51 PM, Dave Page <dp...@pgadmin.org> wrote: > > > On Mon, Apr 9, 2018 at 2:20 PM, Neel Patel <neel.pa...@enterprisedb.com> > wrote: > >> Hi Dave, >> >> On Mon, Apr 9, 2018 at 6:33 PM, Khushboo Vashi < >> khushboo.va...@enterprisedb.com> wrote: >> >>> >>> >>> On Mon, Apr 9, 2018 at 6:19 PM, Dave Page <dp...@pgadmin.org> wrote: >>> >>>> Oh yeah - I forgot to mention that running it in PyCharms seems to >>>> work. The issue comes when using the runtime from what I can see (even >>>> using the exact same venv that works otherwise). >>>> >>>> Didn't try on windows. Let me try. >>> >>>> On Mon, Apr 9, 2018 at 1:46 PM, Murtuza Zabuawala < >>>> murtuza.zabuaw...@enterprisedb.com> wrote: >>>> >>>>> Did not try running pgAdmin4 on windows from git repo. >>>>> Let me get the latest pull and check. >>>>> >>>>> -- >>>>> Regards, >>>>> Murtuza Zabuawala >>>>> EnterpriseDB: http://www.enterprisedb.com >>>>> The Enterprise PostgreSQL Company >>>>> >>>>> >>>>> On Mon, Apr 9, 2018 at 5:53 PM, Dave Page <dp...@pgadmin.org> wrote: >>>>> >>>>>> ... is really not going well today. >>>>>> >>>>>> After arguing with PIP on Mac for some time, I eventually managed to >>>>>> get a build out. That required a manual update of my system to 9.0.3 to >>>>>> ensure TLS 1.2 worked, and then changing to build such that we only force >>>>>> our own build of Psycopg2, and not other Python packages. I *think* these >>>>>> issues are related to the whole PyPi TLS 1.2/PIP 9.0.3 brownouts and >>>>>> other >>>>>> works they've been doing. >>>>>> >>>>>> The Windows build is a whole other ballgame. The build itself runs >>>>>> just fine, but we end up with the following error in the log: >>>>>> >>>>>> Traceback (most recent call last): >>>>>> File "C:/Program Files/pgAdmin 4/v3/web/pgAdmin4.py", line 70, in >>>>>> >>>>>> app = create_app() >>>>>> File "C:\Program Files\pgAdmin 4\v3\web\pgadmin\__init__.py", line >>>>>> 367, in create_app >>>>>> driver.init_app(app) >>>>>> File "C:\Program Files\pgAdmin >>>>>> 4\v3\web\pgadmin\utils\driver\__init__.py", >>>>>> line 40, in init_app >>>>>> DriverRegistry.load_drivers() >>>>>> File "C:\Program Files\pgAdmin >>>>>> 4\v3\web\pgadmin\utils\driver\registry.py", >>>>>> line 88, in load_drivers >>>>>> module = import_module(module_name) >>>>>> File "C:/Program Files/pgAdmin 4/v3/venv\lib\importlib\__init__.py", >>>>>> line 37, in import_module >>>>>> __import__(name) >>>>>> File "C:\Program Files\pgAdmin >>>>>> 4\v3\web\pgadmin\utils\driver\psycopg2\__init__.py", >>>>>> line 26, in >>>>>> from .connection import Connection >>>>>> File "C:\Program Files\pgAdmin >>>>>> 4\v3\web\pgadmin\utils\driver\psycopg2\connection.py", >>>>>> line 25, in >>>>>> from pgadmin.utils.crypto import decrypt >>>>>> File "C:\Program Files\pgAdmin 4\v3\web\pgadmin\utils\crypto.py", >>>>>> line 16, in >>>>>> from Crypto.Cipher import AES >>>>>> File "C:/Program Files/pgAdmin >>>>>> 4/v3/venv/Lib/site-packages\Crypto\Cipher\__init__.py", >>>>>> line 3, in >>>>>> from Crypto.Cipher._mode_ecb import _create_ecb_cipher >>>>>> File "C:/Program Files/pgAdmin >>>>>> 4/v3/venv/Lib/site-packages\Crypto\Cipher\_mode_ecb.py", >>>>>> line 46, in >>>>>> """ >>>>>> File "C:/Program Files/pgAdmin >>>>>> 4/v3/venv/Lib/site-packages\Crypto\Util\_raw_api.py", >>>>>> line 258, in load_pycryptodome_raw_lib >>>>>> raise OSError("Cannot load native module '%s': %s" % (name, ", >>>>>> ".join(attempts))) >>>>>> OSError: Cannot load native module 'Crypto.Cipher._raw_ecb': Trying >>>>>> '_raw_ecb.pyd': [Error 126] The specified module could not be found >>>>>> Exception KeyError: KeyError(3644,) in >>>>> 'C:/Program Files/pgAdmin 4/v3/venv\lib\threading.py'> ignored >>>>>> >>>>>> The module does exist of course in the Crypto\Cipher directory. >>>>>> >>>>> >> Everything works fine on my windows machine with Python 3.5. >> Any specific scenarios ? >> > > Standard release build using Python 2.7; > > make x86 > Let me try with Python 2.7 x86. > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
Re: Building releases...
Hi Dave, On Mon, Apr 9, 2018 at 6:33 PM, Khushboo Vashi < khushboo.va...@enterprisedb.com> wrote: > > > On Mon, Apr 9, 2018 at 6:19 PM, Dave Pagewrote: > >> Oh yeah - I forgot to mention that running it in PyCharms seems to work. >> The issue comes when using the runtime from what I can see (even using the >> exact same venv that works otherwise). >> >> Didn't try on windows. Let me try. > >> On Mon, Apr 9, 2018 at 1:46 PM, Murtuza Zabuawala < >> murtuza.zabuaw...@enterprisedb.com> wrote: >> >>> Did not try running pgAdmin4 on windows from git repo. >>> Let me get the latest pull and check. >>> >>> -- >>> Regards, >>> Murtuza Zabuawala >>> EnterpriseDB: http://www.enterprisedb.com >>> The Enterprise PostgreSQL Company >>> >>> >>> On Mon, Apr 9, 2018 at 5:53 PM, Dave Page wrote: >>> ... is really not going well today. After arguing with PIP on Mac for some time, I eventually managed to get a build out. That required a manual update of my system to 9.0.3 to ensure TLS 1.2 worked, and then changing to build such that we only force our own build of Psycopg2, and not other Python packages. I *think* these issues are related to the whole PyPi TLS 1.2/PIP 9.0.3 brownouts and other works they've been doing. The Windows build is a whole other ballgame. The build itself runs just fine, but we end up with the following error in the log: Traceback (most recent call last): File "C:/Program Files/pgAdmin 4/v3/web/pgAdmin4.py", line 70, in app = create_app() File "C:\Program Files\pgAdmin 4\v3\web\pgadmin\__init__.py", line 367, in create_app driver.init_app(app) File "C:\Program Files\pgAdmin 4\v3\web\pgadmin\utils\driver\__init__.py", line 40, in init_app DriverRegistry.load_drivers() File "C:\Program Files\pgAdmin 4\v3\web\pgadmin\utils\driver\registry.py", line 88, in load_drivers module = import_module(module_name) File "C:/Program Files/pgAdmin 4/v3/venv\lib\importlib\__init__.py", line 37, in import_module __import__(name) File "C:\Program Files\pgAdmin 4\v3\web\pgadmin\utils\driver\psycopg2\__init__.py", line 26, in from .connection import Connection File "C:\Program Files\pgAdmin 4\v3\web\pgadmin\utils\driver\psycopg2\connection.py", line 25, in from pgadmin.utils.crypto import decrypt File "C:\Program Files\pgAdmin 4\v3\web\pgadmin\utils\crypto.py", line 16, in from Crypto.Cipher import AES File "C:/Program Files/pgAdmin 4/v3/venv/Lib/site-packages\Crypto\Cipher\__init__.py", line 3, in from Crypto.Cipher._mode_ecb import _create_ecb_cipher File "C:/Program Files/pgAdmin 4/v3/venv/Lib/site-packages\Crypto\Cipher\_mode_ecb.py", line 46, in """ File "C:/Program Files/pgAdmin 4/v3/venv/Lib/site-packages\Crypto\Util\_raw_api.py", line 258, in load_pycryptodome_raw_lib raise OSError("Cannot load native module '%s': %s" % (name, ", ".join(attempts))) OSError: Cannot load native module 'Crypto.Cipher._raw_ecb': Trying '_raw_ecb.pyd': [Error 126] The specified module could not be found Exception KeyError: KeyError(3644,) in >>> 'C:/Program Files/pgAdmin 4/v3/venv\lib\threading.py'> ignored The module does exist of course in the Crypto\Cipher directory. >>> Everything works fine on my windows machine with Python 3.5. Any specific scenarios ? > Murtuza, Khushboo; have you got it running on pgAdmin recently? -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company >>> >>> >> >> >> -- >> Dave Page >> Blog: http://pgsnake.blogspot.com >> Twitter: @pgsnake >> >> EnterpriseDB UK: http://www.enterprisedb.com >> The Enterprise PostgreSQL Company >> > >
Re: pgAdmin 4 commit: Fix a number of broken connection detection scenarios
Thanks, RM#3249 created for the same. Regards, Neel Patel On Thu, Apr 5, 2018 at 11:27 AM, Akshay Joshi <akshay.jo...@enterprisedb.com > wrote: > Hi Neel > > This issue is not due to the above fix, if you can see the error it is > showing in dashboard.js line no 454 "err = JSON.parse(xhr.responseText);" > that code is from long time. > I have just added an extra check of the readyState in case of server is > down in the above commit. > Though it is a bug can you please create a new RM for this. > > On Thu, Apr 5, 2018 at 10:52 AM, Neel Patel <neel.pa...@enterprisedb.com> > wrote: > >> Hi Akshay, >> >> Due to above commit, when user "Drop" any database it gives exception in >> browser console. >> Check attached screenshot. >> >> Thanks, >> Neel Patel >> >> >> >> On Wed, Mar 21, 2018 at 2:08 PM, Dave Page <dp...@pgadmin.org> wrote: >> >>> Fix a number of broken connection detection scenarios. >>> >>> Branch >>> -- >>> master >>> >>> Details >>> --- >>> https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdif >>> f;h=637f3b9d1a54df8b9a1bfad9e26f27fdea407683 >>> Author: Akshay Joshi <akshay.jo...@enterprisedb.com> >>> >>> Modified Files >>> -- >>> web/pgadmin/dashboard/static/js/dashboard.js | 58 >>> >>> web/pgadmin/static/js/sqleditor/execute_query.js | 62 >>> +++-- >>> .../js/sqleditor/is_new_transaction_required.js| 9 >>> web/pgadmin/tools/sqleditor/__init__.py| 4 +- >>> web/pgadmin/tools/sqleditor/static/js/sqleditor.js | 20 --- >>> .../tools/sqleditor/tests/test_start_query_tool.py | 2 +- >>> .../tools/sqleditor/utils/start_running_query.py | 63 >>> ++ >>> .../utils/tests/test_start_running_query.py| 15 +- >>> .../user_management/static/js/user_management.js | 13 - >>> .../utils/driver/psycopg2/server_manager.py| 1 + >>> .../javascript/sqleditor/execute_query_spec.js | 48 >>> - >>> .../sqleditor/is_new_transaction_required_spec.js | 14 ++--- >>> 12 files changed, 195 insertions(+), 114 deletions(-) >>> >>> >> > > > -- > *Akshay Joshi* > > *Sr. Software Architect * > > > > *Phone: +91 20-3058-9517Mobile: +91 976-788-8246* >
Re: [pgAdmin4]: Fix for RM #3248
Hi, Please find updated patch after fixing the comments. Review it and let me know for comments. Thanks, Neel Patel On Thu, Apr 5, 2018 at 11:32 AM, Neel Patel <neel.pa...@enterprisedb.com> wrote: > Thanks Murtuza & Khushboo. > I will send updated patch. > > Thanks, > Neel Patel > > On Thu, Apr 5, 2018 at 11:29 AM, Khushboo Vashi < > khushboo.va...@enterprisedb.com> wrote: > >> Neel, >> >> Add below code to the top (around line no 8) in >> alertify.pgadmin.defaults.js file will solve the problem. >> >> alertify.defaults.closable = false; >> >> >> Thanks, >> Khushboo >> >> On Thu, Apr 5, 2018 at 11:13 AM, Murtuza Zabuawala < >> murtuza.zabuaw...@enterprisedb.com> wrote: >> >>> Hi Neel, >>> >>> Can we make the change in wrapper instead of changing every where? >>> File: ../web/pgadmin/static/js/alertify.pgadmin.defaults.js >>> >>> >>> -- >>> Regards, >>> Murtuza Zabuawala >>> EnterpriseDB: http://www.enterprisedb.com >>> The Enterprise PostgreSQL Company >>> >>> >>> On Thu, Apr 5, 2018 at 11:04 AM, Neel Patel <neel.pa...@enterprisedb.com >>> > wrote: >>> >>>> Hi, >>>> >>>> Please find attached patch for the fix of RM #3248 - we have modified >>>> alertify confirm dialog to modal dialog. >>>> >>>> Do review it and let me know for comments. >>>> >>>> Thanks, >>>> Neel Patel >>>> >>> >>> >> > RM_3248_v2.patch Description: Binary data
Re: [pgAdmin4]: Fix for RM #3248
Thanks Murtuza & Khushboo. I will send updated patch. Thanks, Neel Patel On Thu, Apr 5, 2018 at 11:29 AM, Khushboo Vashi < khushboo.va...@enterprisedb.com> wrote: > Neel, > > Add below code to the top (around line no 8) in > alertify.pgadmin.defaults.js file will solve the problem. > > alertify.defaults.closable = false; > > > Thanks, > Khushboo > > On Thu, Apr 5, 2018 at 11:13 AM, Murtuza Zabuawala <murtuza.zabuawala@ > enterprisedb.com> wrote: > >> Hi Neel, >> >> Can we make the change in wrapper instead of changing every where? >> File: ../web/pgadmin/static/js/alertify.pgadmin.defaults.js >> >> >> -- >> Regards, >> Murtuza Zabuawala >> EnterpriseDB: http://www.enterprisedb.com >> The Enterprise PostgreSQL Company >> >> >> On Thu, Apr 5, 2018 at 11:04 AM, Neel Patel <neel.pa...@enterprisedb.com> >> wrote: >> >>> Hi, >>> >>> Please find attached patch for the fix of RM #3248 - we have modified >>> alertify confirm dialog to modal dialog. >>> >>> Do review it and let me know for comments. >>> >>> Thanks, >>> Neel Patel >>> >> >> >
[pgAdmin4]: Fix for RM #3248
Hi, Please find attached patch for the fix of RM #3248 - we have modified alertify confirm dialog to modal dialog. Do review it and let me know for comments. Thanks, Neel Patel RM_3248.patch Description: Binary data
Re: Showstopper desktop runtime issue
Hi, On Thu, Mar 22, 2018 at 3:19 PM, Dave Pagewrote: > All, > > As you know, the 3.0 release is currently on hold as we discovered late > yesterday that the re-vamped desktop runtime will not run on Gnome 3.26 and > later. This is because the GTK project, and later Gnome, have removed > support for the System Tray on which the new runtime relies. > > They have replaced it with a notification mechanism, however this doesn't > really meet our needs as what we want is a place (the tray icon) to attach > a menu to control the pgAdmin server; we don't really use notifications as > such. > > I see a number of possible ways around this: > > 1) Return to the previous runtime. I think this is at best a short-term > solution, as the re-visited Annulen version of the QtWebKit seems to be > getting little attention at the moment, and this would re-introduce many > known bugs caused by WebKit. > > 2) Re-work the current runtime code to remove the tray icon, and utilise > desktop/start menu items to signal the running instance to show the logs, > configure the server, exit etc. This should work, but will be kinda klunky. > > 3) Put effort into polishing Joao's Electron based runtime. This might be > a good long term solution as it would remove the need to have any C++ code > of our own, and might allow us to use Electron's update mechanism to do > software updates. The downsides are that we would lose support for dockable > tabs (new windows only), and it wouldn't work on CentOS/RHEL 6 which we > currently support. > > Thoughts and comments please folks? How do we want to proceed? I'm > currently leaning towards 2 for v3, and possibly moving to 3 in the long > term. > As per our previous efforts on Qt's web rendering framework, I am not in favor of adding it again as it add lots of dependency and complexity. I would suggest to go for option 2 - To re-work the current runtime code and find out how to get already running instance of pgadmin4. > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
Re: pgAdmin 4 commit: Support for external tables in GPDB. Fixes #3168
pdb#80323#\\node.sql') == FAIL: runTest (pgadmin.browser.server_groups.servers.databases.external_tables.tests.test_external_tables_view.TestExternalTablesView) #properties When retrieving the properties of a external table and the table exists, it return the properties and status 200 -- Traceback (most recent call last): File "C:\Python34\Lib\unittest\mock.py", line 1142, in patched return func(*args, **keywargs) File "C:\Projects\pgadmin4\web\pgadmin\browser\server_groups\servers\databases\external_tables\tests\test_external_tables_view.py", line 320, in runTest self.__test_properties() File "C:\Python34\Lib\unittest\mock.py", line 1142, in patched return func(*args, **keywargs) File "C:\Projects\pgadmin4\web\pgadmin\browser\server_groups\servers\databases\external_tables\tests\test_external_tables_view.py", line 419, in __test_properties **self.expect_render_template_called_with File "C:\Python34\Lib\unittest\mock.py", line 777, in assert_called_with raise AssertionError(_error_message()) from cause AssertionError: Expected call: render_template(template_name_or_list='sql/#gpdb#80323#/get_table_information.sql', table_oid=11) Actual call: render_template(template_name_or_list='sql/#gpdb#80323#\\get_table_information.sql', table_oid=11) -- Ran 256 tests in 77.123s FAILED (failures=7, errors=4, skipped=25) == Test Result Summary == PostgreSQL 9.6: 234 tests passed 3 tests failed: TestExternalTablesView (#node When retrieving the information about 1 external table and table does not exist, it return an error message and status 404, #node When retrieving the information about 1 external table and an error happens while executing the query, it return an internal server error and status 500, #nodes When retrieving the nodes and the database has 2 external tables, it return 2 child nodes and status 200, #nodes When retrieving the information about 1 external table and the table exists, it return external node information and status 200, #nodes When retrieving the nodes and an error happens while executing the query, it return an internal server error and status 500, #properties When retrieving the properties of a external table and the table exists, it return the properties and status 200, #nodes When retrieving the nodes and the database does not have external tables, it return no child nodes and status 200) ChangePasswordTestCase (TestCase for Changing Valid_Password) TestTemplateCreate (When rendering GreenPlum 5.3 template, when no distribution is present, when no primary key is present, it returns "DISTRIBUTED RANDOMLY", When rendering GreenPlum 5.3 template, when distribution is present, it returns "DISTRIBUTED BY (attr1, attr2, attr4)", When rendering GreenPlum 5.3 template, when no distribution is present, when primary key is present, it returns "DISTRIBUTED BY (attr_primary_key)") 19 tests skipped: ResourceGroupsGetTestCase (Get resource groups) TableSpaceDeleteTestCase (Check Tablespace Node) ResourceGroupsDeleteTestCase (Delete resource groups) SynonymDeleteTestCase (Fetch synonym Node URL) TestSSLConnection (Test for SSL connection) PackageAddTestCase (Fetch Package Node URL) SynonymPutTestCase (Fetch synonym Node URL) TablespaceGetTestCase (Check Tablespace Node) SynonymAddTestCase (Default Node URL) PackagePutTestCase (Fetch Package Node URL) TableAddTestCase (Create Range partitioned table with 2 partitions, Create List partitioned table with 2 partitions) PackageGetTestCase (Fetch Package Node URL) PackageDeleteTestCase (Fetch Package Node URL) TableSpaceAddTestCase (Check Tablespace Node) ResourceGroupsAddTestCase (Add resource groups) SynonymGetTestCase (Fetch synonym Node URL) ResourceGroupsPutTestCase (Put resource groups) TableSpaceUpdateTestCase (Check Tablespace Node) TableUpdateTestCase (Attach partition to existing ran
Re: [pgAdmin4][runtime][patch]: Fix for RM#2679
Hi Dave, On Tue, Nov 21, 2017 at 2:36 PM, Dave Page <dp...@pgadmin.org> wrote: > > > On Tue, Nov 21, 2017 at 9:02 AM, Neel Patel <neel.pa...@enterprisedb.com> > wrote: > >> Hi Dave, >> >> On Mon, Nov 20, 2017 at 8:20 PM, Dave Page <dp...@pgadmin.org> wrote: >> >>> Hi >>> >>> On Mon, Nov 20, 2017 at 1:10 PM, Neel Patel <neel.pa...@enterprisedb.com >>> > wrote: >>> >>>> Hi, >>>> >>>> Please find attached patch to fix RM#2679. >>>> >>>> *Issue:-* >>>> Getting started links does not open second time from "Dashboard" panel >>>> if User close runtime tab and open any URL again. >>>> >>>> *Analysis:-* >>>> As in runtime Qt application, when user defined "target=_new" then >>>> "createWindow" signal is called but when user close that new windows and >>>> again click on link then "createWindow" signal is not getting called so >>>> from user point view nothing will happen. >>>> >>>> *Solution:-* >>>> To make it work in both runtime and web application, changed "target" >>>> attribute to "_blank" so that "createWindow" signal will be called every >>>> time when user click on any link. >>>> >>> >>> I think this is a partial workaround for the problem. We link to >>> external sites such as postgresql.org - what happens if that tries to >>> open something with target="_new"? It should be expected to work as well. I >>> think we need to fix the underlying problem, not try to work around it. >>> >> >> Yes. You are right. We can implement the actual underlying problem but >> curious to know the difference between "_blank" and "_new" target attribute. >> >> I didn't find any reference document for target attribute value "_new". I >> searched below links. >> >> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/A#attr-target >> >> https://msdn.microsoft.com/en-us/library/system.web.ui.webco >> ntrols.hyperlink.target(v=vs.110).aspx#Anchor_0 >> Thoughts ? >> > > Hmm, interesting. So, per the spec we should be using _blank - I'll commit > the patch to fix that. > Yes. We should use _blank instead of _new. > > That means that _new *should* work as any other named target - open it if > it doesn't exist and navigate within it. > Yes - As per my knowledge, "target=_new" means URL to be opened in new frame with name="_new". > > In other words, I think we still have a bug here; using _new (much like > using, say, "foo") should still open a new tab if an earlier one has been > closed - much as a browser would. > As per the docs, we should use "_blank". Do you feel we should fix in runtime as well for _new, If yes - I can work on that. > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
Re: [pgAdmin4][patch][runtime]: RM#2829, RM#2491 - pgAdmin4 crashes while saving CSV data from Query tool
Hi Dave, I have tried for 350K rows with query given by you but not able to reproduce the hang issue. I have put some debug statement in Qt Signal's handler. Can you please apply this debug patch and provide me console output if possible ? Thanks, Neel Patel On Fri, Nov 17, 2017 at 3:13 PM, Neel Patel <neel.pa...@enterprisedb.com> wrote: > Hi Dave, > > On Fri, Nov 17, 2017 at 3:09 PM, Dave Page <dp...@pgadmin.org> wrote: > >> >> >> On Fri, Nov 17, 2017 at 9:36 AM, Neel Patel <neel.pa...@enterprisedb.com> >> wrote: >> >>> Hi Dave, >>> >>> On Fri, Nov 17, 2017 at 2:42 PM, Dave Page <dp...@pgadmin.org> wrote: >>> >>>> >>>> >>>> On Fri, Nov 17, 2017 at 8:45 AM, Neel Patel < >>>> neel.pa...@enterprisedb.com> wrote: >>>> >>>>> Hi Dave, >>>>> >>>>> On Thu, Nov 16, 2017 at 8:13 PM, Dave Page <dp...@pgadmin.org> wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> On Thu, Nov 16, 2017 at 1:47 PM, Neel Patel < >>>>>> neel.pa...@enterprisedb.com> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Adding information. >>>>>>> >>>>>>> With this patch, RM#2715 should also be resolved. >>>>>>> >>>>>>> Thanks, >>>>>>> Neel Patel >>>>>>> >>>>>>> On Thu, Nov 16, 2017 at 7:01 PM, Neel Patel < >>>>>>> neel.pa...@enterprisedb.com> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I am able to reproduce the crash while downloading and save data in >>>>>>>> CSV file from query tool. >>>>>>>> >>>>>>>> Please find attached updated patch with below changes after reading >>>>>>>> Qt documentation. >>>>>>>> >>>>>>>>- Added new signal "readyRead". As per the Qt documentation, >>>>>>>>this signal will be emitted when data is ready from IO channel for >>>>>>>> large >>>>>>>>amount of data transfer between server and client. >>>>>>>>- Ready read and DownloadInProgress signal is very quick in >>>>>>>>call so we should not do large operation inside that slot because >>>>>>>> for >>>>>>>>downloading big data it may possible of frequent call of those >>>>>>>> signals >>>>>>>>which may cause the crash or missing data to write inside the file >>>>>>>> so >>>>>>>>removed unnecessary logic from that slot. >>>>>>>>- Fixed the crash while opening IODevice with NULL handle. >>>>>>>> >>>>>>>> With above changes, I have tested with same data as earlier and it >>>>>>>> is working as expected without crashing the application. >>>>>>>> >>>>>>>> Do review it and let me know for comments. >>>>>>>> >>>>>>> >>>>>> My first test was on Mac using Qt 5.8 with webkit, and when I >>>>>> attempted to download the results from a 300K row query, it basically >>>>>> hung >>>>>> showing the Downloading File progress indicator. It let me cancel it and >>>>>> carried on working, but hung again the next time I tried the CSV >>>>>> download. >>>>>> Each time it seems to download some data - from the same query I've seen >>>>>> 2.8MB, 5.1MB and 1.5MB. >>>>>> >>>>> >>>>> We are using "*downloadProgress*" signal to update the progress bar >>>>> and here we are getting "readData" as bytes but "totalData" is unknown so >>>>> we received "totalData" as -1 because Qt doesn't know the total size of >>>>> the >>>>> file we are getting from server but when we open "pgAdmin4" website in >>>>> another link and try to download some binary or source at that time we are >>>>> getting "totalData" as known size and we are displaying the progress bar >>>>> corre
Re: [pgAdmin4][patch][runtime]: RM#2829, RM#2491 - pgAdmin4 crashes while saving CSV data from Query tool
Hi Dave, On Thu, Nov 16, 2017 at 8:13 PM, Dave Page <dp...@pgadmin.org> wrote: > Hi > > On Thu, Nov 16, 2017 at 1:47 PM, Neel Patel <neel.pa...@enterprisedb.com> > wrote: > >> Hi, >> >> Adding information. >> >> With this patch, RM#2715 should also be resolved. >> >> Thanks, >> Neel Patel >> >> On Thu, Nov 16, 2017 at 7:01 PM, Neel Patel <neel.pa...@enterprisedb.com> >> wrote: >> >>> Hi, >>> >>> I am able to reproduce the crash while downloading and save data in CSV >>> file from query tool. >>> >>> Please find attached updated patch with below changes after reading Qt >>> documentation. >>> >>>- Added new signal "readyRead". As per the Qt documentation, this >>>signal will be emitted when data is ready from IO channel for large >>> amount >>>of data transfer between server and client. >>>- Ready read and DownloadInProgress signal is very quick in call so >>>we should not do large operation inside that slot because for downloading >>>big data it may possible of frequent call of those signals which may >>> cause >>>the crash or missing data to write inside the file so removed unnecessary >>>logic from that slot. >>>- Fixed the crash while opening IODevice with NULL handle. >>> >>> With above changes, I have tested with same data as earlier and it is >>> working as expected without crashing the application. >>> >>> Do review it and let me know for comments. >>> >> > My first test was on Mac using Qt 5.8 with webkit, and when I attempted to > download the results from a 300K row query, it basically hung showing the > Downloading File progress indicator. It let me cancel it and carried on > working, but hung again the next time I tried the CSV download. Each time > it seems to download some data - from the same query I've seen 2.8MB, 5.1MB > and 1.5MB. > We are using "*downloadProgress*" signal to update the progress bar and here we are getting "readData" as bytes but "totalData" is unknown so we received "totalData" as -1 because Qt doesn't know the total size of the file we are getting from server but when we open "pgAdmin4" website in another link and try to download some binary or source at that time we are getting "totalData" as known size and we are displaying the progress bar correctly. Here, Qt sending the signal "downloadProgress" with unknown totalData size as -1 so we update the progress bar with 100% so from user point of view it looks like hang but it is downloading and writing to file at back ground. if we apply the same patch in windows then it display running progress bar so user can know something happening at back end side. I think it is same as browser - if we download big size file from server then it keep on downloading the file without displaying total size. What should we do here ? Should we create one custom progress bar dialog with moving cursor or something other so that user can know that activity is doing at backend ? Thoughts ? > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
Re: [pgAdmin4][patch][runtime]: RM#2829, RM#2491 - pgAdmin4 crashes while saving CSV data from Query tool
Hi, Adding information. With this patch, RM#2715 should also be resolved. Thanks, Neel Patel On Thu, Nov 16, 2017 at 7:01 PM, Neel Patel <neel.pa...@enterprisedb.com> wrote: > Hi, > > I am able to reproduce the crash while downloading and save data in CSV > file from query tool. > > Please find attached updated patch with below changes after reading Qt > documentation. > >- Added new signal "readyRead". As per the Qt documentation, this >signal will be emitted when data is ready from IO channel for large amount >of data transfer between server and client. >- Ready read and DownloadInProgress signal is very quick in call so we >should not do large operation inside that slot because for downloading big >data it may possible of frequent call of those signals which may cause the >crash or missing data to write inside the file so removed unnecessary logic >from that slot. >- Fixed the crash while opening IODevice with NULL handle. > > With above changes, I have tested with same data as earlier and it is > working as expected without crashing the application. > > Do review it and let me know for comments. > > Thanks, > Neel Patel >
[pgAdmin4][patch][runtime]: RM#2829, RM#2491 - pgAdmin4 crashes while saving CSV data from Query tool
Hi, I am able to reproduce the crash while downloading and save data in CSV file from query tool. Please find attached updated patch with below changes after reading Qt documentation. - Added new signal "readyRead". As per the Qt documentation, this signal will be emitted when data is ready from IO channel for large amount of data transfer between server and client. - Ready read and DownloadInProgress signal is very quick in call so we should not do large operation inside that slot because for downloading big data it may possible of frequent call of those signals which may cause the crash or missing data to write inside the file so removed unnecessary logic from that slot. - Fixed the crash while opening IODevice with NULL handle. With above changes, I have tested with same data as earlier and it is working as expected without crashing the application. Do review it and let me know for comments. Thanks, Neel Patel RM_2829_RM_2491.patch Description: Binary data
[pgAdmin4][Patch]: RM#2716 - Automatic detect and fix value of "HKEY_CLASSES_ROOT\.css\Content Type"
Hi, Please find attached patch file with the fix of RM#2716. *Issue:-* In Windows OS, if registry "HKEY_CLASSES_ROOT\.css\Content Type" value is not "text/css" then application get rendering issue and GUI is not displayed properly. *Solution:-* When pgAdmin4 application starts, it checks for registry value above and it differs from "text/css", application will change the value and notifies the user about the same. Do review it and let me know for comments. Thanks, Neel Patel RM_2716.patch Description: Binary data
[pgAdmin4][patch][runtime]: RM#2443 - No prompt while exiting application
Hi, Please find attached patch to fix RM#2443 - No prompt while existing from main pgAdmin4 runtime browser window. Do review it and let me know for comments. Thanks, Neel Patel RM_2443.patch Description: Binary data
Re: [pgAgent][Patch] Fixing connection pool leak
Hi Ashesh, I just added condition before delete the job otherwise it looks good. Correct me if I am wrong. if (job != NULL) { delete job; job = NULL; } I have created two instances of pgagent on database cluster. As of now not able to see any leak and keep you updated if found anything. @Robert - Can you also test at your environment and keep us updated for any leak ? Thanks, Neel Patel On Mon, Oct 23, 2017 at 10:30 AM, Ashesh Vashi < ashesh.va...@enterprisedb.com> wrote: > Hi Rob, > > How about this? > > > -- > > Thanks & Regards, > > Ashesh Vashi > EnterpriseDB INDIA: Enterprise PostgreSQL Company > <http://www.enterprisedb.com> > > > *http://www.linkedin.com/in/asheshvashi* > <http://www.linkedin.com/in/asheshvashi> > > On Sat, Oct 21, 2017 at 8:36 PM, Rob Emery <re-pg...@codeweavers.net> > wrote: > >> Hi, >> >> Following on from https://www.postgresql.org/mes >> sage-id/CA%2BOCxoz4tONxSpd1rdU-9SPKRzucz8Bar2CXkEDnCwV6H77Zy >> A%40mail.gmail.com >> >> I think I've identified and fixed the issue, please see the patch >> attached. >> >> As I understand it when there are multiple pgagent instances and they >> clash executing a job (i.e rc != 1 on job.cpp:38), the loser of the >> conflict's thread will never be executed (i.e. job.cpp:418 >> JobThread::Entry), which is responsible for deleting the job owned by the >> thread, meaning that the connection is never returned to the pool. By >> moving the delete of the job into the destructor, we can assure that the >> connection is tidied up in both cases as the thread is deleted in the error >> case explicitly in pgAgent.cpp:185. >> >> The only possibly unintended difference that I can see with doing this is >> that the log "Completed job: %s" is now output when before it wasn't, >> however I think this new behaviour is actually correct as the job object is >> completed at that time. >> >> Thanks, >> Rob >> >> <https://codeweavers.net> >> >> >> <http://us15.campaign-archive1.com/?u=fcb361cfa194cf70551bc5169=f556b0bf09> >> Codeweavers >> October >> Newsletter >> <http://us15.campaign-archive1.com/?u=fcb361cfa194cf70551bc5169=f556b0bf09> >> *l *Auto Trader extends partnership with Codeweavers >> <https://codeweavers.net/company-blog/auto-trader-extends-partnership-with-codeweavers-to-power-finance-on-auto-trader-websites> >> >> >> <https://codeweavers.net/automotive-vision-conference-agenda> >> >> *What are Codeweavers doing to gear up for GDPR? >> <https://codeweavers.net/company-blog/what-are-codeweavers-doing-to-gear-up-for-gdpr>* >> >> >> >> *Phone:* 0800 021 0888 * Email: *contac...@codeweavers.net >> *Codeweavers Ltd* | Barn 4 | Dunston Business Village | Dunston | ST18 >> 9AB >> Registered in England and Wales No. 04092394 | VAT registration no. 974 >> 9705 63 >> >> <https://www.linkedin.com/company/codeweavers-limited> >> <https://vimeo.com/codeweaversltd> [image: >> https://plus.google.com/b/105942302039373248738/+CodeweaversNet] >> <https://plus.google.com/b/105942302039373248738/+CodeweaversNet> [image: >> https://twitter.com/CodeweaversTeam] >> <https://twitter.com/CodeweaversTeam> >> > > connection_pool_v3.patch Description: Binary data
Re: v2.0-rc1 not starting, runtime not building
Hi, I don't know the installed packages on your system but what I can help only - Download Qt 5.5 installers from "https://download.qt.io/archive/qt/; and install it on custom path ( e.g. /opt/Qt5.5" and use "qmake" installed in that directory during compilation and let us know result. Thanks, Neel Patel On Thu, Sep 14, 2017 at 2:32 PM, Willy-Bas Loos <willy...@gmail.com> wrote: > > On Thu, Sep 14, 2017 at 10:35 AM, Neel Patel <neel.pa...@enterprisedb.com> > wrote: > >> Surely, there is something wrong with your Qt installation. >> Can you please try to install required "*-dev" packages for qt5 ? >> >> >> Sure, i just don't know how to find out which ones. libraies.txt only > says "QT". > So i have: > qtdeclarative5-dev:amd64 > qtdeclarative5-dev-tools > libqt5opengl5-dev:amd64 > libqt5webkit5-dev:amd64 > pyqt5-dev > and now also pyqt5-dev-tools (doesn't change the outcome/output) > > all in version 5.5.1 > > Interestingly, qmake only displays the QT warning when I add "DEFINES > +=PGADMIN4_USE_WEBKIT" > To me, that implies that the wrong webkit is being used. I do have a few > packages that are similar: > > (pgadmin4) wbloos@wb:~/python-files/pgadmin4/runtime$ dpkg -l|grep > webkit|cut -f 3 -d ' ' > gir1.2-webkit2-4.0:amd64 > libqt5webkit5:amd64 > libqt5webkit5-dev:amd64 > libqtwebkit4:amd64 > libqtwebkit4:i386 > libwebkit2gtk-4.0-37:amd64 > libwebkit2gtk-4.0-37-gtk2:amd64 > libwebkitgtk-3.0-0:amd64 > libwebkitgtk-3.0-common > > I'm not sure how they got there, i haven't tried what dependents they > have. I could try removing them but i will probably run into some trouble. > > Willy-Bas Loos >
Re: pgAdmin 4 v1.6 Released!
Hi, Thanks, Neel Patel On Jul 14, 2017 5:31 AM, "Shira Bezalel" <sh...@sfei.org> wrote: I downloaded the Windows pgAdmin 1.6 version, and after launching it, it simply shows a black display. My colleague also on Windows 10 had the same experience. Does this sound like a known problem? It is not an issue with 1.6. This is due to previous "ActiveQt" testing build using different zoom level. To resolve the issue press Ctrl 0. Shira On Thu, Jul 13, 2017 at 11:18 AM, Lazaro Garcia <lazaro3...@gmail.com> wrote: > The download links are wrong, the links downloads 1.5 and not 1.6. > > > > Regards. > > > > *De:* Dave Page [mailto:dp...@pgadmin.org] > *Enviado el:* jueves, 13 de julio de 2017 11:18 a. m. > *Para:* pgAdmin Support; pgadmin-hackers > *Asunto:* pgAdmin 4 v1.6 Released! > > > > The pgAdmin Development Team are pleased to announce the release of > pgAdmin 4 version 1.6. This release of pgAdmin 4 includes over 70 bug fixes > and a dozen new features. For details, please see the release notes ( > https://www.pgadmin.org/docs/pgadmin4/dev/release_notes_1_6.html). > > > > Notable changes in this release include: > > > > * Significant performance improvements on Windows, massively reducing > initial load time and improving UI response for the vast majority of users > during testing. > > > > * Enhancements to the Query Tool enabling the viewing of large query > resultsets far more quickly. For example, a simple test query with 96K rows > rendered results within 1 second vs. 22 seconds in pgAdmin III during > testing! > > > > * A major rewrite of the Query History tab allows browsing of queries > executed in the query tool with full details including the entire query, in > a much nicer user interface. > > > > * The Desktop Runtime now supports detachable tabs, allowing the Query > Tool and Debugger to be opened in new tabs and then moved to alternate > displays (from 1.5 this was possible in web mode only) > > > > * The Query Tool's Results Grid has been overhauled with a new, sleek look > an feel supporting selection of arbitrary rows, columns or blocks of cells > with full copy support and column sizing retention. > > > > * The Dashboard tab can now be closed if desired, to minimise query > traffic resulting from graph updates. > > > > For more information, checkout the online documentation, and of course the > download page: > > > > Docs: https://www.pgadmin.org/docs/pgadmin4/dev/index.html > > > > Download: https://www.pgadmin.org/download > > > > > > -- > > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake >
[pgAdmin4][runtime]: Fix RM #2558
Hi, Please find attached patch file for the fix of below issue in runtime. RM #2558 - Tab bar on main window vanishes when closing child via tab button I have tested with all 3 platforms. Do review it and let me know for comments. Thanks, Neel Patel RM_2558.patch Description: Binary data