Downgrade psycopg2 to 2.7.7 (or whatever came before 2.8). Apparently they broke backwards compatibility:-(
-- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK:http://www.enterprisedb.com The Enterprise PostgreSQL Company > On 4 Apr 2019, at 17:33, Shaheed Haque <shaheedha...@gmail.com> wrote: > > 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
