Re: Database broken after using pgadmin 'backup' on OSX - Mailing list pgadmin-support
From | Darren Duncan |
---|---|
Subject | Re: Database broken after using pgadmin 'backup' on OSX |
Date | |
Msg-id | 2fa1dc9f-d822-1ec5-0026-60e189de5a62@darrenduncan.net Whole thread Raw |
In response to | Re: Database broken after using pgadmin 'backup' on OSX (Conor McNally <theconor@gmail.com>) |
List | pgadmin-support |
I have no further specific advice to offer. Someone more familiar with the relevant source code will have to do it. -- Darren Duncan On 2017-07-14 2:21 PM, Conor McNally wrote: > Hi Darren, > > Thanks for the tip. I upgraded to pgAdmin 4 v1.6 and tried again. > > Immediately BEFORE running the pgAdmin backup tool the symbolic links look like > this: > > ls -l /usr/local/lib/ | grep postg > lrwxr-xr-x 1 conor admin 48 29 Jun 21:06 libecpg.6.8.dylib -> > ../Cellar/postgresql/9.6.2/lib/libecpg.6.8.dylib > lrwxr-xr-x 1 conor admin 46 29 Jun 21:06 libecpg.6.dylib -> > ../Cellar/postgresql/9.6.2/lib/libecpg.6.dylib > lrwxr-xr-x 1 conor admin 40 29 Jun 21:06 libecpg.a -> > ../Cellar/postgresql/9.6.2/lib/libecpg.a > lrwxr-xr-x 1 conor admin 44 29 Jun 21:06 libecpg.dylib -> > ../Cellar/postgresql/9.6.2/lib/libecpg.dylib > lrwxr-xr-x 1 conor admin 55 29 Jun 21:06 libecpg_compat.3.8.dylib -> > ../Cellar/postgresql/9.6.2/lib/libecpg_compat.3.8.dylib > lrwxr-xr-x 1 conor admin 53 29 Jun 21:06 libecpg_compat.3.dylib -> > ../Cellar/postgresql/9.6.2/lib/libecpg_compat.3.dylib > lrwxr-xr-x 1 conor admin 47 29 Jun 21:06 libecpg_compat.a -> > ../Cellar/postgresql/9.6.2/lib/libecpg_compat.a > lrwxr-xr-x 1 conor admin 51 29 Jun 21:06 libecpg_compat.dylib -> > ../Cellar/postgresql/9.6.2/lib/libecpg_compat.dylib > lrwxr-xr-x 1 conor admin 44 29 Jun 21:06 libpgcommon.a -> > ../Cellar/postgresql/9.6.2/lib/libpgcommon.a > lrwxr-xr-x 1 conor admin 45 29 Jun 21:06 libpgfeutils.a -> > ../Cellar/postgresql/9.6.2/lib/libpgfeutils.a > lrwxr-xr-x 1 conor admin 42 29 Jun 21:06 libpgport.a -> > ../Cellar/postgresql/9.6.2/lib/libpgport.a > lrwxr-xr-x 1 conor admin 51 29 Jun 21:06 libpgtypes.3.7.dylib -> > ../Cellar/postgresql/9.6.2/lib/libpgtypes.3.7.dylib > lrwxr-xr-x 1 conor admin 49 29 Jun 21:06 libpgtypes.3.dylib -> > ../Cellar/postgresql/9.6.2/lib/libpgtypes.3.dylib > lrwxr-xr-x 1 conor admin 43 29 Jun 21:06 libpgtypes.a -> > ../Cellar/postgresql/9.6.2/lib/libpgtypes.a > lrwxr-xr-x 1 conor admin 47 29 Jun 21:06 libpgtypes.dylib -> > ../Cellar/postgresql/9.6.2/lib/libpgtypes.dylib > lrwxr-xr-x 1 conor admin 46 29 Jun 21:06 libpq.5.9.dylib -> > ../Cellar/postgresql/9.6.2/lib/libpq.5.9.dylib > lrwxr-xr-x 1 conor admin 44 29 Jun 21:06 libpq.5.dylib -> > ../Cellar/postgresql/9.6.2/lib/libpq.5.dylib > lrwxr-xr-x 1 conor admin 38 29 Jun 21:06 libpq.a -> > ../Cellar/postgresql/9.6.2/lib/libpq.a > lrwxr-xr-x 1 conor admin 42 29 Jun 21:06 libpq.dylib -> > ../Cellar/postgresql/9.6.2/lib/libpq.dylib > lrwxr-xr-x 1 conor admin 41 29 Jun 21:06 postgresql -> > ../Cellar/postgresql/9.6.2/lib/postgresql > > Immediately AFTER running the pgAdmin backup tool (to take a plain text dump of > the schema) I have this: > >> ls -l /usr/local/lib/ | grep postg > lrwxr-xr-x 1 conor admin 48 29 Jun 21:06 libecpg.6.8.dylib -> > ../Cellar/postgresql/9.6.2/lib/libecpg.6.8.dylib > lrwxr-xr-x 1 conor admin 46 29 Jun 21:06 libecpg.6.dylib -> > ../Cellar/postgresql/9.6.2/lib/libecpg.6.dylib > lrwxr-xr-x 1 conor admin 40 29 Jun 21:06 libecpg.a -> > ../Cellar/postgresql/9.6.2/lib/libecpg.a > lrwxr-xr-x 1 conor admin 44 29 Jun 21:06 libecpg.dylib -> > ../Cellar/postgresql/9.6.2/lib/libecpg.dylib > lrwxr-xr-x 1 conor admin 55 29 Jun 21:06 libecpg_compat.3.8.dylib -> > ../Cellar/postgresql/9.6.2/lib/libecpg_compat.3.8.dylib > lrwxr-xr-x 1 conor admin 53 29 Jun 21:06 libecpg_compat.3.dylib -> > ../Cellar/postgresql/9.6.2/lib/libecpg_compat.3.dylib > lrwxr-xr-x 1 conor admin 47 29 Jun 21:06 libecpg_compat.a -> > ../Cellar/postgresql/9.6.2/lib/libecpg_compat.a > lrwxr-xr-x 1 conor admin 51 29 Jun 21:06 libecpg_compat.dylib -> > ../Cellar/postgresql/9.6.2/lib/libecpg_compat.dylib > lrwxr-xr-x 1 conor admin 44 29 Jun 21:06 libpgcommon.a -> > ../Cellar/postgresql/9.6.2/lib/libpgcommon.a > lrwxr-xr-x 1 conor admin 45 29 Jun 21:06 libpgfeutils.a -> > ../Cellar/postgresql/9.6.2/lib/libpgfeutils.a > lrwxr-xr-x 1 conor admin 42 29 Jun 21:06 libpgport.a -> > ../Cellar/postgresql/9.6.2/lib/libpgport.a > lrwxr-xr-x 1 conor admin 51 29 Jun 21:06 libpgtypes.3.7.dylib -> > ../Cellar/postgresql/9.6.2/lib/libpgtypes.3.7.dylib > lrwxr-xr-x 1 conor admin 49 29 Jun 21:06 libpgtypes.3.dylib -> > ../Cellar/postgresql/9.6.2/lib/libpgtypes.3.dylib > lrwxr-xr-x 1 conor admin 43 29 Jun 21:06 libpgtypes.a -> > ../Cellar/postgresql/9.6.2/lib/libpgtypes.a > lrwxr-xr-x 1 conor admin 47 29 Jun 21:06 libpgtypes.dylib -> > ../Cellar/postgresql/9.6.2/lib/libpgtypes.dylib > lrwxr-xr-x 1 conor admin 46 29 Jun 21:06 libpq.5.9.dylib -> > ../Cellar/postgresql/9.6.2/lib/libpq.5.9.dylib > lrwxr-xr-x 1 conor admin 44 29 Jun 21:06 libpq.5.dylib -> > ../Cellar/postgresql/9.6.2/lib/libpq.5.dylib > lrwxr-xr-x 1 conor admin 38 29 Jun 21:06 libpq.a -> > ../Cellar/postgresql/9.6.2/lib/libpq.a > lrwxr-xr-x 1 conor admin 42 29 Jun 21:06 libpq.dylib -> > ../Cellar/postgresql/9.6.2/lib/libpq.dylib > lrwxrwxrwx 1 conor admin 49 14 Jul 22:00 postgresql -> > /usr/local/Cellar/postgresql/9.5.3/lib/postgresql > > So something has downgraded the last entry in the list and version number no > longer matches the other libraries. > > Any ideas why this should be? As mentioned previously I have installed (and > upgraded) postgres via brew, and pgAdmin by drag&drop from the dmg into my > applications folder. Originally I did have a EnterpriseDB build of Postgres > installed, but I deleted that some time ago when I switched to brew. > > Thanks for any further advice you can give. > > Kind regards, > > Conor McNally > > On Fri, Jun 30, 2017 at 12:18 AM, Darren Duncan <darren@darrenduncan.net > <mailto:darren@darrenduncan.net>> wrote: > > On 2017-06-29 1:06 PM, Conor McNally wrote: > > By 'no longer working' it means that the postrges libraries have been > messed up > and I get the following error when I try to connect via pyscopg2 (python > v3.5.2_3, pyscopg2 v2.6.2): > > File > "/Users/conor/virt_env/conor/lib/python3.5/site-packages/psycopg2/extras.py", > line 288, in execute > return super(NamedTupleCursor, self).execute(query, vars) > psycopg2.InternalError: could not load library > "/usr/local/lib/postgresql/plpgsql.so": > dlopen(/usr/local/lib/postgresql/plpgsql.so, 10): Symbol not found: > _DatumIsReadWriteExpandedObject > Referenced from: /usr/local/lib/postgresql/plpgsql.so > Expected in: /usr/local/opt/postgresql/bin/postgres > in /usr/local/lib/postgresql/plpgsql.so > > > I find the only way to fix the problem is to run "brew switch postgresql > 9.6.2". I don't really know what that command does but the database > connections > are OK after I run it. Also, the database backup file has been created > successfully as far as I can tell: I have not yet attempted to restore > it. One > other thing is I don't get a confirmation message in the pgAdmin console > the way > I used to. > > > I'll tell you what that command does. > > I have some experience with perlbrew/brew, which is a package manager of > sorts that supports having multiple concurrent installations of different > versions of something, and also or typically builds from source. > > The "switch" command basically updates some symlinks for some installed > thing so that a specific version is referenced by them. For example, if you > had versions X and Y of package Foo installed, you use "brew switch" to > indicate that when you invoke "Foo" you get either version X or Y. > > $ brew help switch > brew switch name version: > Symlink all of the specific version of name's install to Homebrew prefix. > > It would appear that something was changing your symlinks. Or possibly a > local shell path was being altered. > > I can't tell you what is making these changes though. > > -- Darren Duncan > > > >
pgadmin-support by date: