On Mon, Apr 23, 2018 at 3:48 PM, Jim Taylor <jtay...@jtdata.com> wrote:

> I haven’t done this for a while but just tried a straightforward SQL
> update of the “marc” field in the biblio.record_entry table and get the
> error below.   Have done this 10’s of thousands of times within the last
> year or so with no problem.  Currently running version 2.12.6.   Did
> something change which would purposely cause such an action to fail?
> Suggestions?   Thanks.

[began this yesterday, in the meantime Josh has replied along the same
lines -jeff]


This is a PostgreSQL search_path related issue.

At least one function in your database is expecting to be run with a search
path that contains the "evergreen" schema.

The default PostgreSQL search_path is:
"$user", public

Common ways that the "evergreen" schema ends up in your PostgreSQL

1. connecting to the database as a PostgreSQL user named "evergreen" --
which means that the special value "$user" translates to the "evergreen"

2. setting the database-level search_path setting with ALTER DATABASE

3. setting search_path manually from the psql shell using a command like:
SET search_path = evergreen,public,pg_catalog;

The last option (item 3) only lasts for as long as the life of your session.

>From a psql shell, if you run a SHOW search_path, you'll probably find your
search path is set to the default, and I'd also guess that you're connected
to PostgreSQL as a user named something other than "evergreen" -- perhaps
as the "postgres" user.

There are a number of reasons why things worked before and aren't working
for you now. One common gotcha is that database settings (shown with \drds
in the psql shell) are not preserved by pg_dump -- they are stored at the
cluster level, so you'll only get them with pg_dumpall. (This isn't a
recommendation to change your use of pd_dump / pg_dumpall.)

You can manually set the search_path in your psql session as in item 3
above and you'll probably find your query works as expected.

Your other connections to PostgreSQL (from OpenSRF services) may already be
receiving the correct search_path if they connect as the database user

Be aware that in some rare (bordering on theoretical) cases, setting /
correcting a search path in a persistent way (using methods 1 or 2 above)
can expose latent issues, including issues that may not be immediately

Armed with that knowledge / warning, you'll probably want to investigate
adjusting the database setting for search_path (which will not take effect
for clients until they reconnect).

Good luck!


Reply via email to