[pgadmin-hackers] Re: PATCH: RM# 1679 - Background process for "restore" not reporting status back to pgAdmin
Hi
On Wed, Jan 11, 2017 at 12:28 PM, Ashesh Vashi <
ashesh.va...@enterprisedb.com> wrote:
> Hi Dave,
>
> On Wed, Jan 11, 2017 at 12:03 PM, Dave Page wrote:
>
>>
>> KeyError: u'end_time'
>>
>> The status file contains:
>>
>> {"start_time": "2017-01-11 06:27:20.939703 +", "pid": 49363,
>> "exit_code": 0, "end_time": "2017-01-11 06:27:28.613456 +"}
>>
>
> Thanks for reviewing the patch.
> Please find the updated patch.
>
> Changes:
> - Using now ValueError instead of json.JSONDecodeError, which is subclass
> of ValueError, to allow to it to work with 2.6+ python.
> - Checking the existence of value in dict before accessing it.
>
>
>
That seems to work for me in a brief test on my Mac. :-)
Fahar; are you able to apply and test this patch on Windows and Linux, in
server and desktop modes? Basically all the external processes should be
tested - backup, restore & maintenance (vacuum) etc). I don't have any VMs
available at the moment due to travel.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
RM1679_v7.patch
Description: Binary data
--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] Driver Module
Hi Dave, Thanks for the pointer. We realized that many of the changes we would need to make for supporting Greenplum would need to go where there is pg version checking throughout the code. This is because unlike PPAS which mostly adds additional features, Greenplum is based on postgres 8.3. It looks like much of the version checking logic is repeated at points where the features are differentiated by postgres version. It might make sense at this point to refactor the way that feature flagging is done to be a little bit more unified between server types and postgres versions so that we could for example have logic along the lines of: feature_enablement = FeatureEnablement(postgres_flavor, postgres_version) #... if(feature_enablement.check_internal_triggers ): # feature call here and then in a feature enablement class, reference the various versions and flavors of postgres. Any thoughts on this? Thanks, Tira and George On Sun, Jan 8, 2017 at 4:57 AM, Dave Page wrote: > Hi > > On Friday, January 6, 2017, George Gelashvili > wrote: > >> Hi there, >> >> We are working on connecting Greenplum to pgAdmin4. Currently we are >> exploring how modules work in pgAdmin. In an earlier off-thread email it >> was suggested we look at "the EDB PPAS" as an example of a driver class. We >> are not entirely clear on what that means. >> >> We found: >> - the BaseDriver in web/pgadmin/utils/driver, documented: >> https://www.pgadmin.org/docs4/1.x/code_snippets.html?highlig >> ht=driver#basedriver >> - things that look EDB-related in web/pgadmin/utils/driver/psyco >> pg2/__init__.py >> >> Is it a good idea to keep looking for EDB PPAS as an example of a driver? >> Does anyone know exactly where it lives? >> > > I believe 99% of it is simply inherited from the base driver, and (some > of?) the rest of it is in web/pgadmin/browser/server_ > groups/servers/ppas.py. > > Ashesh, can you help here? You know that code infinitely better than I do. > > Thanks. > > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > >
[pgadmin-hackers] Building server without Apache
Pgadmin gurus: I'm trying to create a canonical container image for pgAdmin4 Server. However, using Apache is kind of heavyweight for a container. Has anyone run pgAdmin4 against something lighter weight? -- Josh Berkus Containers & Databases Oh My! -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] Building server without Apache
On Thu, Jan 12, 2017 at 7:42 AM, Josh Berkus wrote: > Pgadmin gurus: > > I'm trying to create a canonical container image for pgAdmin4 Server. > However, using Apache is kind of heavyweight for a container. Has > anyone run pgAdmin4 against something lighter weight? If memory serves, the reason why we recommend Apache is that at the time I last tested, it was the only one of Apache, Lighttpd and Nginx which would support single-process, multi-thread WSGI apps. Having a single process is essential, due to the global connection manager used by pgAdmin - it's the only way we can guarantee affinity between the user session and the database session. If you can make that work with servers other than Apache (someone recently suggested Gunicorn might be able to help), then I'd love to hear about it. There are no other special requirements of pgAdmin, so really that's all that stands in your way. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] Driver Module
Hi On Wed, Jan 11, 2017 at 10:24 PM, George Gelashvili wrote: > Hi Dave, > > Thanks for the pointer. > We realized that many of the changes we would need to make for supporting > Greenplum would need to go where there is pg version checking throughout the > code. This is because unlike PPAS which mostly adds additional features, > Greenplum is based on postgres 8.3. Isn't Heikki fixing that for your next release? > It looks like much of the version checking logic is repeated at points where > the features are differentiated by postgres version. > > It might make sense at this point to refactor the way that feature flagging > is done to be a little bit more unified between server types and postgres > versions so that we could for example have logic along the lines of: > > feature_enablement = FeatureEnablement(postgres_flavor, postgres_version) > > #... > > if(feature_enablement.check_internal_triggers ): > # feature call here > > and then in a feature enablement class, reference the various versions and > flavors of postgres. > > Any thoughts on this? I worry that the list of features would end up being huge - we're not just talking about basic things like whether DDL triggers are supported, but the catalog schema (e.g. procpid vs. pid in pg_stat_activity) and small things like whether a particular GUC can be set on a tablespace. Ultimately, you have to do a version check at some point though (unless you're proposing to do something similar to probing the DOM in a browser at runtime). Doesn't GP's version string contain additional info beyond '8.3'? In pgAdmin 3 we had a EdbMinimumVersion(int major, int minor) function in the connection class that basically did: return isEdb && BackendMinimumVersion(x, y); Something like that could check other elements of the GP version number. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] Driver Module
On Wed, Jan 11, 2017 at 8:07 PM, Dave Page wrote: > Hi > > On Wed, Jan 11, 2017 at 10:24 PM, George Gelashvili > wrote: > > Hi Dave, > > > > Thanks for the pointer. > > We realized that many of the changes we would need to make for supporting > > Greenplum would need to go where there is pg version checking throughout > the > > code. This is because unlike PPAS which mostly adds additional features, > > Greenplum is based on postgres 8.3. > > Isn't Heikki fixing that for your next release? > The current release is 8.2, we aren't trying to make that work with pgAdmin4. Heikki did a yeomans work and the next release will be based on 8.3. Future releases should be more than one Postgres version at a time but there was a lot of cleanup to do before we could start the Postgres merging. > > > It looks like much of the version checking logic is repeated at points > where > > the features are differentiated by postgres version. > > > > It might make sense at this point to refactor the way that feature > flagging > > is done to be a little bit more unified between server types and postgres > > versions so that we could for example have logic along the lines of: > > > > feature_enablement = FeatureEnablement(postgres_flavor, > postgres_version) > > > > #... > > > > if(feature_enablement.check_internal_triggers ): > > # feature call here > > > > and then in a feature enablement class, reference the various versions > and > > flavors of postgres. > > > > Any thoughts on this? > > I worry that the list of features would end up being huge - we're not > just talking about basic things like whether DDL triggers are > supported, but the catalog schema (e.g. procpid vs. pid in > pg_stat_activity) and small things like whether a particular GUC can > be set on a tablespace. > > Ultimately, you have to do a version check at some point though > (unless you're proposing to do something similar to probing the DOM in > a browser at runtime). Doesn't GP's version string contain additional > info beyond '8.3'? In pgAdmin 3 we had a EdbMinimumVersion(int major, > int minor) function in the connection class that basically did: > > return isEdb && BackendMinimumVersion(x, y); > > Something like that could check other elements of the GP version number. > Greenplum is about to start leveraging semantic versioning. The version number for the next release will be 5.0.0. > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > > -- > Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgadmin-hackers >
[pgadmin-hackers] Re: PATCH: RM# 1679 - Background process for "restore" not reporting status back to pgAdmin
Sure Dave,
Will test this after applying the patch today and update the status
accordingly.
On Wed, Jan 11, 2017 at 6:19 PM, Dave Page wrote:
> Hi
>
> On Wed, Jan 11, 2017 at 12:28 PM, Ashesh Vashi <
> ashesh.va...@enterprisedb.com> wrote:
>
>> Hi Dave,
>>
>> On Wed, Jan 11, 2017 at 12:03 PM, Dave Page wrote:
>>
>>>
>>> KeyError: u'end_time'
>>>
>>> The status file contains:
>>>
>>> {"start_time": "2017-01-11 06:27:20.939703 +", "pid": 49363,
>>> "exit_code": 0, "end_time": "2017-01-11 06:27:28.613456 +"}
>>>
>>
>> Thanks for reviewing the patch.
>> Please find the updated patch.
>>
>> Changes:
>> - Using now ValueError instead of json.JSONDecodeError, which is subclass
>> of ValueError, to allow to it to work with 2.6+ python.
>> - Checking the existence of value in dict before accessing it.
>>
>>
>>
> That seems to work for me in a brief test on my Mac. :-)
>
> Fahar; are you able to apply and test this patch on Windows and Linux, in
> server and desktop modes? Basically all the external processes should be
> tested - backup, restore & maintenance (vacuum) etc). I don't have any VMs
> available at the moment due to travel.
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
--
Syed Fahar Abbas
Quality Management Group
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
Re: [pgadmin-hackers] Building server without Apache
On Jan 12, 2017 4:56 AM, "Dave Page" wrote: On Thu, Jan 12, 2017 at 7:42 AM, Josh Berkus wrote: > Pgadmin gurus: > > I'm trying to create a canonical container image for pgAdmin4 Server. > However, using Apache is kind of heavyweight for a container. Has > anyone run pgAdmin4 against something lighter weight? If memory serves, the reason why we recommend Apache is that at the time I last tested, it was the only one of Apache, Lighttpd and Nginx which would support single-process, multi-thread WSGI apps. Having a single process is essential, due to the global connection manager used by pgAdmin - it's the only way we can guarantee affinity between the user session and the database session. If you can make that work with servers other than Apache (someone recently suggested Gunicorn might be able to help), then I'd love to hear about it. There are no other special requirements of pgAdmin, so really that's all that stands in your way. Uwsgi might also be worth investigating. It's pretty light and supports an hybrid model where ISTM it would work if you just set number of processes to 1 (but I haven't tried it with pgadmin specifically. /Magnus
