Re: Windows testing required: Updated runtime - Mailing list pgadmin-hackers

>No - PostgreSQL builds on Windows dropped GSSAPI in favour of SSPI some years ago. That functionality is provided by the underlying libpq, not pgAdmin - though pgAdmin 1.6 does allow you to specify the host address as >well as hostname/address which many people need with Kerberos for example.

 

Not sure I understand this.

Windows works fine with gssapi (the server is on a linux box).

I make gssapi connections all the time with npgsql library and the web version of pgadmin and terminal software so I don’t have to use passwords.

It just doesn’t seem to work with the desktop version of pgadmin.

 

>Before Webpack patch:-

 

>It took ~20 seconds. This 20 seconds includes when user double click on application ( timing of python server start + page load )

 

So Neel also gets 20 second start up (before webpack) .  At least it’s not just me.  I look forward to having those 7 secs.

 

On a more positive note I do find the browsing of nodes and retrieving table SQL seems to be snappier in 1.6.

 

>Will there be a web install package.

 

What I meant was will there be a pgadmin4-v1-web package update.

 

Oh and as an aside I think you made the right decision going with a web app.  It’s definitely the future .

After these performance problems have been addressed.

It’s not easy creating a feature rich web app and I appreciate all the work you guys have done on this.

Just keep an open mind that your end users may have issues you don’t.  There are so many environmental factors to consider.

 

Mike

 

From: Dave Page [mailto:dpage@pgadmin.org]
Sent: 11 July 2017 16:36

To: Mike Surcouf
Cc: McDonaldR; pgadmin-hackers; pgAdmin Support
Subject: Re: Windows testing required: Updated runtime

 

 

 

On Tue, Jul 11, 2017 at 4:14 PM, Mike Surcouf <mikes@surcouf.co.uk> wrote:

> Try pressing Ctrl 0 (Control zero)

 

Yes that did it.

I also needed to reset layout for it to stick.

 

OK, good.

 

 

Start-up time still 25 secs to dash board so still slow for me (sorry but it’s a fact).

For comparison Server install start up is 5 seconds to dash board.

 

Hmm, that is still slow. I get about 11 seconds on Windows 10, running on VMware on my MacBook Pro. Any AV software etc. that may be slowing things?

 

 

1.       Does the desktop support GSSAPI.  It doesn’t seem to work for me (I get error FATAL: GSSAPI authentication failed for user "postgres").   Server install works fine.

No - PostgreSQL builds on Windows dropped GSSAPI in favour of SSPI some years ago. That functionality is provided by the underlying libpq, not pgAdmin - though pgAdmin 1.6 does allow you to specify the host address as well as hostname/address which many people need with Kerberos for example.

 

2.       Did you webpack all the things for 1.6?

No, unfortunately the patch wasn't ready. I have a WIP version, and it's looking good; Neel reported the following using the runtime you have:

 

Before Webpack patch:-

 

It took ~20 seconds. This 20 seconds includes when user double click on application ( timing of python server start + page load )

 

After Webpack patch:-

 

It took ~13 seconds ( timing of python server start + page load ).

 

We got ~7 seconds improvement with webpack on same machine & same Qt configuration and this will be useful in windows performance issue as well :)

 

 I expect this to be in 1.7, which we'll aim to get out fairly quickly (vacations allowing)

 

3.       Will there be a web install package.

There is a source tarball and Python wheel available at http://developer.pgadmin.org/~dpage/1.6/

 

 Thanks!

 

Thanks

 

Mike

 

 

From: Dave Page [mailto:dpage@pgadmin.org]
Sent: 11 July 2017 15:43
To: Mike Surcouf
Cc: McDonaldR; pgadmin-hackers; pgAdmin Support
Subject: Re: Windows testing required: Updated runtime

 

Hi

 

On Tue, Jul 11, 2017 at 2:47 PM, Mike Surcouf <mikes@surcouf.co.uk> wrote:

Hi Dave

 

v1.6

Show splash then backround of main window then hangs forever. pgadmin4.log is 0 bytes

 

Try pressing Ctrl 0 (Control zero) to reset the zoom level. The experimental ActiveQt build used a different scaling factor for the zoom which may have been saved in the registry. I found that on my machine - it had zoomed in so far that I just had a few pixels expanded to fit the screen.

 

v1.3

Uninstalled then reinstalled 1.3 (which was the last version that worked).and all is ok again

 

But I guess it works on your machine so it must be something wrong with my setup

 

Hard to see what though, if it's not the zoom. I have tested on Windows 7 as well as Windows 10, so it *should* work.

 

--

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