I can login, but when I click on "Servers", nothing happens on screen
and the error log gets this:
[2019-04-04 16:10:10 +0000] [5850] [INFO] Starting gunicorn 19.9.0
[2019-04-04 16:10:10 +0000] [5850] [INFO] Listening at:
unix:/home/ubuntu/pgadmin.sock (5850)
[2019-04-04 16:10:10 +0000] [5850] [INFO] Using worker: gthread
[2019-04-04 16:10:10 +0000] [5853] [INFO] Booting worker with pid: 5853
2019-04-04 16:10:25,732: ERROR flask.app:
'psycopg2.extensions.Column' object has no attribute '_asdict'
Traceback (most recent call last):
File "/usr/local/lib/python3.6/dist-packages/flask/app.py", line
1813, in full_dispatch_request
rv = self.dispatch_request()
File "/usr/local/lib/python3.6/dist-packages/flask/app.py", line
1799, in dispatch_request
return self.view_functions[rule.endpoint](**req.view_args)
File "/usr/local/lib/python3.6/dist-packages/flask/views.py", line 88, in view
return self.dispatch_request(*args, **kwargs)
File
"/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/browser/utils.py",
line 259, in dispatch_request
return method(*args, **kwargs)
File
"/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/browser/utils.py",
line 309, in children
children.extend(module.get_nodes(*args, **kwargs))
File
"/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/browser/server_groups/servers/__init__.py",
line 127, in get_nodes
in_recovery, wal_paused = recovery_state(conn, manager.version)
File
"/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/browser/server_groups/servers/__init__.py",
line 52, in recovery_state
status, result = connection.execute_dict(recovery_check_sql)
File
"/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/utils/driver/psycopg2/connection.py",
line 1202, in execute_dict
desc.to_dict() for desc in cur.ordered_description()
File
"/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/utils/driver/psycopg2/connection.py",
line 1202, in <listcomp>
desc.to_dict() for desc in cur.ordered_description()
File
"/usr/local/lib/python3.6/dist-packages/pgadmin4/pgadmin/utils/driver/psycopg2/cursor.py",
line 94, in to_dict
ores = OrderedDict(self.orig_col._asdict())
AttributeError: 'psycopg2.extensions.Column' object has no attribute '_asdict'
It seems as though the version of psycopg2 is not what is expected,
rather than anything to do with "builtins.SERVER_MODE = True"? By way
of full disclosure, I do in fact have both psycopg2 AND
psycopg2-binary installed [1] but some quick experiments removing one
or other did not solve the problem.
Have I overlooked something?
Thanks, Shaheed
[1] this came up in another discussion recently, and it seems that I
ought to remove the psycopg2-binary though 4.2 was OK with this setup.
On Thu, 4 Apr 2019 at 15:04, Dave Page <dp...@pgadmin.org> wrote:
>
> Hi
>
> It worked fine when I tested it. If you don't get any errors and you get a
> login prompt, it should all be good.
>
> On Thu, Apr 4, 2019 at 3:01 PM Shaheed Haque <shaheedha...@gmail.com> wrote:
>>
>> Hi Dave,
>>
>> I'm just migrating to the fixes in 4.4. Can I just double check one
>> thing? In my original hack, I needed to create a link "wsgi.py" ->
>> "pgAdmin4.py", so the the corresponding gunicorn command is something
>> like this:
>>
>> gunicorn ... --bind unix:/.../pgadmin.sock wsgi:application
>>
>> Now, in the documentation updates as part of this fix, the last
>> argument to that line reads "pgAdmin4:app" and not "wsgi:application".
>> The reason I though I needed to use the wsgi.py file is that it
>> contains these lines amongst other:
>>
>> # Ensure the global server mode is set.
>> builtins.SERVER_MODE = True
>>
>> I'm not sure if, by following the updated docs, I am missing a
>> necessary setting?
>>
>> Thanks, Shaheed
>>
>> On Tue, 5 Mar 2019 at 09:11, Dave Page <dp...@pgadmin.org> wrote:
>> >
>> > You're welcome. Sorry it took so long to realise the main issue was only
>> > applicable to Gunicorn!
>> >
>> > On Mon, Mar 4, 2019 at 6:29 PM Shaheed Haque <srha...@theiet.org> wrote:
>> >>
>> >> Dave,
>> >>
>> >> Thanks for taking this forward, I look forward to 4.4! I also noted with
>> >> interest that we can use "pgAdmin4:app" rather than my hacky link to the
>> >> pgAdmin4.wsgi, so that means a completely hack-free solution :-).
>> >>
>> >>
>> >> Shaheed
>> >>
>> >> On Mon, 4 Mar 2019 at 16:33, Dave Page <dp...@pgadmin.org> wrote:
>> >>>
>> >>> Hi
>> >>>
>> >>> On Fri, Mar 1, 2019 at 9:30 AM Shaheed Haque <srha...@theiet.org> wrote:
>> >>>>
>> >>>> OK, I got it working. This is how...
>> >>>>
>> >>>> On Mon, 25 Feb 2019 at 23:25, Shaheed Haque <srha...@theiet.org> wrote:
>> >>>> >
>> >>>> > Hi,
>> >>>> >
>> >>>> > I'm a relative noob when it comes to the world of nginx, wsgi and so
>> >>>> > forth, but I do have several other things working (a Django app under
>> >>>> > gunicorn and the RabbitMQ web UI directly behind nginx). However, I'm
>> >>>> > rather stuck getting pgAdmin4 to run at
>> >>>> > http://mydomain.com:80/pgadmin behind nginx. Is there a simple,
>> >>>> > up-to-date example of how to do this (I'm running the latest, v4.2,
>> >>>> > of pgAdmin4)?
>> >>>> >
>> >>>> > I'm aware of threads such as
>> >>>> > https://www.postgresql.org/message-id/2197768425D7F5479A0FFB3FEC212F7FF602B871%40aesmail.surcouf.local,
>> >>>> > and several others but not been able to come up with a clear
>> >>>> > approach:
>> >>>> >
>> >>>> > One of the several variables I'm struggling to understand is the
>> >>>> > choice of whether to run pgAdmin4.py on port 5050 directly behind
>> >>>> > nginx, or as a WSGI app under gunicorn. I assume the latter should be
>> >>>> > easier to set up, but I've tried both (modelled on what I have
>> >>>> > working, and various references). One combination I tried was:
>> >>>> >
>> >>>> > - Creating a softlink from pgadmin4.py to pgAdmin4.wsgi
>> >>>> > - Using gunicorn to run the pgadmin4.py to a unix domain socket like
>> >>>> > this:
>> >>>> >
>> >>>> > $ /usr/local/bin/gunicorn -w 1 --bind
>> >>>> > unix:/home/ubuntu/pgadmin.sock pgadmin4:application
>> >>>> >
>> >>>> > - Serving behind nginx like this:
>> >>>> >
>> >>>> > location /pgadmin {
>> >>>> > rewrite ^/pgadmin/(.*) /$1 break;
>> >>>> > include proxy_params;
>> >>>> > proxy_pass http://unix:/home/ubuntu/pgadmin.sock;
>> >>>> > }
>> >>>> >
>> >>>> > But all I get is a stubborn 404. Any pointers welcome...
>> >>>>
>> >>>> First, I got over the 404s (caused, it seems, by me forgetting just how
>> >>>> much my browser had cached :-0). The next problem was with the nginx
>> >>>> config fragment: as soon as pgAdmin responded, it of course started the
>> >>>> browser looking for top level URLs such as /browser and /static which
>> >>>> are obviously not under /pgadmin. The to this key was a piece of code
>> >>>> in https://stackoverflow.com/a/50515636/6332554, which basically adds
>> >>>> the concept of a SCRIPT_NAME by hacking a small wodge of code into
>> >>>> pgAdmin4.py.
>> >>>>
>> >>>> The SCRIPT_NAME is set by an nginx fragment like this:
>> >>>>
>> >>>> location /pgadmin {
>> >>>> rewrite ^/pgadmin/(.*)$ /\$1 break;
>> >>>> include proxy_params;
>> >>>> proxy_pass http://unix:/home/$CLOUD_USER/pgadmin.sock;
>> >>>> proxy_set_header X-Script-Name /pgadmin;
>> >>>> }
>> >>>>
>> >>>> In addition to that change, as previously noted, I needed to create a
>> >>>> link to pgAdmin4.wsgi to allow gunicorn to pick it up. I change the
>> >>>> name I used so I ended up with the link being "wsgi.py" ->
>> >>>> "pgAdmin4.py", so the the corresponding gunicorn command is something
>> >>>> like this:
>> >>>>
>> >>>> gunicorn ... --bind unix:/.../pgadmin.sock wsgi:application
>> >>>>
>> >>>> Now, IIUC, the notion of SCRIPT_NAME is somewhat standard, and needed
>> >>>> to solve this issue of running pgAdmin in server mode, but sharing the
>> >>>> domain with other applications. Would there be interest in making the
>> >>>> needed code an integral part of pgAdmin? If so, I'd be happy to file a
>> >>>> feature request.
>> >>>>
>> >>>> Thanks, Shaheed
>> >>>
>> >>>
>> >>> Thanks for your work on this.
>> >>>
>> >>> I've committed a change to add the reverse proxy code, and to put some
>> >>> more examples in the docs:
>> >>> https://redmine.postgresql.org/projects/pgadmin4/repository/revisions/f401def044c8b47974d58c71ff9e6f71f34ef41d
>> >>>
>> >>> FWIW, I think the reason that this was an issue for so long is that you
>> >>> don't need the extra code if you use mod_wsgi or uWSGI - it's only
>> >>> needed with Gunicorn. I'll let you guess which of those technologies I'm
>> >>> most familiar with!
>> >>>
>> >>> Unfortunately this commit won't make the 4.3 release later this week,
>> >>> but it will be in 4.4. The instructions will still be good for scenarios
>> >>> other than Gunicorn in a sub-directory though.
>> >>>
>> >>> --
>> >>> 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
>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
