Обсуждение: Database broken after using pgadmin 'backup' on OSX
Hi,
Can anyone help with the following problem?* postgres 9.6.2 locally installed with brew
* pgAdmin 4 v1.5 installed directly from websiteFile "/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
On 29/06/17 21:06, Conor McNally wrote: > Hi, > > Can anyone help with the following problem? > > Since upgrading to pgAdmin 4 v1.5 on macOS Sierra (v10.12.5), it seems > my database is 'broken' every time I use the pgAdmin 'Backup' tool. > > Here's what happens: > * macOS Sierra v10.12.5 > * postgres 9.6.2 locally installed with brew > * pgAdmin 4 v1.5 installed directly from website > * database is running fine > * use the pgAdmin Tools / Backup... utility to take a full back-up > * database is no longer working > > 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. > > Can anybody help with the above problem? It has only started happening > since I upgraded to pgAdmin 4 v1.5. Before that (with pgAdmin 4 v1.4) > everything was fine. I use neither Mac nor Python, but as pgAdmin 4 is Python-based I'd hazard a wild guess that it's doing something to include paths (or whatever the relevant term is). Ray. -- Raymond O'Donnell :: Galway :: Ireland rod@iol.ie
> On 29 Jun 2017, at 21:06, Conor McNally <theconor@gmail.com> wrote: > > Hi, > > Can anyone help with the following problem? > > Since upgrading to pgAdmin 4 v1.5 on macOS Sierra (v10.12.5), it seems my database is 'broken' every time I use the pgAdmin'Backup' tool. > > Here's what happens: > * macOS Sierra v10.12.5 > * postgres 9.6.2 locally installed with brew > * pgAdmin 4 v1.5 installed directly from website > * database is running fine > * use the pgAdmin Tools / Backup... utility to take a full back-up > * database is no longer working > > By 'no longer working' it means that the postrges libraries have been messed up and I get the following error when I tryto 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 commanddoes but the database connections are OK after I run it. Also, the database backup file has been created successfullyas far as I can tell: I have not yet attempted to restore it. One other thing is I don't get a confirmationmessage in the pgAdmin console the way I used to. > > Can anybody help with the above problem? It has only started happening since I upgraded to pgAdmin 4 v1.5. Before that(with pgAdmin 4 v1.4) everything was fine. pgAdmin uses it's own private virtual environment (including libpq and friends). I honestly don't see how it could affectthe system Python, let alone a virtual envy from a completely different version.
By no means an expert but I see: * An environment installed using 'brew' * Some virt_env * A mish-mash of libraries from different lib directories in the error I know this sounds ridiculous, but I wonder if the OP performed the task until such time they got the error. And then rebooted (or at least logged out and logged in - i.e. clear their library paths, library cache and so forth which is best guaranteed by a reboot but at least logging out and maybe starting a new terminal). I'd hedge a bet there's more than one `plgpsql.so` on the system and they're subtly incompatible with each other. DSL > -----Original Message----- > From: Dave Page [mailto:dpage@pgadmin.org] > Sent: Thursday, 29 June 2017 5:20 PM > To: Conor McNally <theconor@gmail.com> > Cc: pgadmin-support@lists.postgresql.org > Subject: Re: Database broken after using pgadmin 'backup' on OSX > > > > > On 29 Jun 2017, at 21:06, Conor McNally <theconor@gmail.com> > wrote: > > > > Hi, > > > > Can anyone help with the following problem? > > > > Since upgrading to pgAdmin 4 v1.5 on macOS Sierra (v10.12.5), it seems > my database is 'broken' every time I use the pgAdmin 'Backup' tool. > > > > Here's what happens: > > * macOS Sierra v10.12.5 > > * postgres 9.6.2 locally installed with brew > > * pgAdmin 4 v1.5 installed directly from website > > * database is running fine > > * use the pgAdmin Tools / Backup... utility to take a full back-up > > * database is no longer working > > > > 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. > > > > Can anybody help with the above problem? It has only started > happening since I upgraded to pgAdmin 4 v1.5. Before that (with > pgAdmin 4 v1.4) everything was fine. > > pgAdmin uses it's own private virtual environment (including libpq and > friends). I honestly don't see how it could affect the system Python, let > alone a virtual envy from a completely different version.
Hi,
Yes I do have two versions of plpgsql.so but it wasn't a problem before.>locate plpgsql.so
/usr/local/Cellar/postgresql/9.5.3/lib/postgresql/plpgsql.so
/usr/local/Cellar/postgresql/9.6.2/lib/postgresql/plpgsql.so
All terminals are affected immediately after running the backup tool: before and after reboot. The "brew switch" command is the only thing I've found that fixes it.
I don't really know how brew works though. Do you think there something I can do to fix my set-up?
Cheers,
Conor
On Thu, Jun 29, 2017 at 10:32 PM, David Lloyd <lloy0076@adam.com.au> wrote:
By no means an expert but I see:
* An environment installed using 'brew'
* Some virt_env
* A mish-mash of libraries from different lib directories in the error
I know this sounds ridiculous, but I wonder if the OP performed the task
until such time they got the error. And then rebooted (or at least
logged out and logged in - i.e. clear their library paths, library cache
and so forth which is best guaranteed by a reboot but at least logging
out and maybe starting a new terminal).
I'd hedge a bet there's more than one `plgpsql.so` on the system and
they're subtly incompatible with each other.
DSL
> -----Original Message-----
> From: Dave Page [mailto:dpage@pgadmin.org]
> Sent: Thursday, 29 June 2017 5:20 PM
> To: Conor McNally <theconor@gmail.com>
> Cc: pgadmin-support@lists.postgresql.org
> Subject: Re: Database broken after using pgadmin 'backup' on OSX
>
>
>
> > On 29 Jun 2017, at 21:06, Conor McNally <theconor@gmail.com>
> wrote:
> >
> > Hi,
> >
> > Can anyone help with the following problem?
> >
> > Since upgrading to pgAdmin 4 v1.5 on macOS Sierra (v10.12.5), it
seems
> my database is 'broken' every time I use the pgAdmin 'Backup' tool.
> >
> > Here's what happens:
> > * macOS Sierra v10.12.5
> > * postgres 9.6.2 locally installed with brew
> > * pgAdmin 4 v1.5 installed directly from website
> > * database is running fine
> > * use the pgAdmin Tools / Backup... utility to take a full back-up
> > * database is no longer working
> >
> > 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.
> >
> > Can anybody help with the above problem? It has only started
> happening since I upgraded to pgAdmin 4 v1.5. Before that (with
> pgAdmin 4 v1.4) everything was fine.
>
> pgAdmin uses it's own private virtual environment (including libpq and
> friends). I honestly don't see how it could affect the system Python,
let
> alone a virtual envy from a completely different version.
Sadly, I don’t have a Mac at the moment so I can’t investigate the internals of “brew switch”; that does tell me something though – if “brew switch” fixes the problem then figuring out what it’s changing when it switches may help trace the actual issue.
In varying orders of possibilities:
1. Does “brew switch” have a “let’s be RIDICULOUSLY verbose” command line switch or environment variable?
2. I think OS X/Darwin have “strace” but I know that the BSD subsystems have the equivalent if that’s a Linux-ism?
3. Does OS X have Dtrace?
4. I wonder if it would be possible to see a snapshot of the underlying /usr/local (probably) before and after a “brew switch” (zfs snapshtos but I don’t think OS X is usually sitting on ZFS but if you have a full backup of /usr e.g. by OS X’s backup manager or you do daily backups [!] it may be possible?)
Given that “brew switch” does fix it, as you say, if you can figure out what it’s changing (I suspect it’s symlinking .dlyibs and .sos and other libraries) and then find out what other thing is changing that.
DSL
From: Conor McNally [mailto:theconor@gmail.com]
Sent: Thursday, 29 June 2017 6:00 PM
To: pgadmin-support@lists.postgresql.org
Subject: Re: Database broken after using pgadmin 'backup' on OSX
Hi,
Yes I do have two versions of plpgsql.so but it wasn't a problem before.
>locate plpgsql.so
/usr/local/Cellar/postgresql/9.5.3/lib/postgresql/plpgsql.so
/usr/local/Cellar/postgresql/9.6.2/lib/postgresql/plpgsql.so
Previously I performed backup using the earlier version of pgAdmin 4 and before that I used pgAdmin 3.
All terminals are affected immediately after running the backup tool: before and after reboot. The "brew switch" command is the only thing I've found that fixes it.
I don't really know how brew works though. Do you think there something I can do to fix my set-up?
Cheers,
Conor
On Thu, Jun 29, 2017 at 10:32 PM, David Lloyd <lloy0076@adam.com.au> wrote:
By no means an expert but I see:
* An environment installed using 'brew'
* Some virt_env
* A mish-mash of libraries from different lib directories in the error
I know this sounds ridiculous, but I wonder if the OP performed the task
until such time they got the error. And then rebooted (or at least
logged out and logged in - i.e. clear their library paths, library cache
and so forth which is best guaranteed by a reboot but at least logging
out and maybe starting a new terminal).
I'd hedge a bet there's more than one `plgpsql.so` on the system and
they're subtly incompatible with each other.
DSL
> -----Original Message-----
> From: Dave Page [mailto:dpage@pgadmin.org]
> Sent: Thursday, 29 June 2017 5:20 PM
> To: Conor McNally <theconor@gmail.com>
> Cc: pgadmin-support@lists.postgresql.org
> Subject: Re: Database broken after using pgadmin 'backup' on OSX
>
>
>
> > On 29 Jun 2017, at 21:06, Conor McNally <theconor@gmail.com>
> wrote:
> >
> > Hi,
> >
> > Can anyone help with the following problem?
> >
> > Since upgrading to pgAdmin 4 v1.5 on macOS Sierra (v10.12.5), it
seems
> my database is 'broken' every time I use the pgAdmin 'Backup' tool.
> >
> > Here's what happens:
> > * macOS Sierra v10.12.5
> > * postgres 9.6.2 locally installed with brew
> > * pgAdmin 4 v1.5 installed directly from website
> > * database is running fine
> > * use the pgAdmin Tools / Backup... utility to take a full back-up
> > * database is no longer working
> >
> > 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.
> >
> > Can anybody help with the above problem? It has only started
> happening since I upgraded to pgAdmin 4 v1.5. Before that (with
> pgAdmin 4 v1.4) everything was fine.
>
> pgAdmin uses it's own private virtual environment (including libpq and
> friends). I honestly don't see how it could affect the system Python,
let
> alone a virtual envy from a completely different version.
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
Hi Darren,
Thanks for the tip. I upgraded to pgAdmin 4 v1.6 and tried again.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
On Fri, Jun 30, 2017 at 12:18 AM, Darren Duncan <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/psy copg2/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
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 > > > >