Re: UUID generation problem - Mailing list pgsql-general
From | Adrian Klaver |
---|---|
Subject | Re: UUID generation problem |
Date | |
Msg-id | cb082ecb-56f2-7e3d-90db-4680470ecaea@aklaver.com Whole thread Raw |
In response to | Re: UUID generation problem ("James B. Byrne" <byrnejb@harte-lyne.ca>) |
Responses |
Re: UUID generation problem
|
List | pgsql-general |
On 10/5/20 9:59 AM, James B. Byrne wrote: > > > On Mon, October 5, 2020 12:51, Tom Lane wrote: >> "James B. Byrne" <byrnejb@harte-lyne.ca> writes: >>> [root@accounting-2 ~ (master)]# psql --dbname=idempiere >>> --username=idempiere_dbadmin --host=localhost >>> Password for user idempiere_dbadmin: >>> psql (11.8) >>> Type "help" for help. >> >>> idempiere=# select current_schemas(true); >>> current_schemas >>> ------------------------ >>> {adempiere,pg_catalog} >>> (1 row) >> >>> idempiere=# select uuid_generate_v4(); >>> ERROR: function uuid_generate_v4() does not exist >>> LINE 1: select uuid_generate_v4(); >>> ^ >>> HINT: No function matches the given name and argument types. You might need >>> to >>> add explicit type casts. >>> idempiere=# select public.uuid_generate_v4(); >>> uuid_generate_v4 >>> -------------------------------------- >>> 5ba19b69-ec8e-4d8e-8968-7c84eccc4351 >>> (1 row) >> >> Well, at least here we have consistent results: "public" is not in >> your search_path. (Presumably, "show search_path" would confirm >> that.) The question is what did you do differently before that >> led to the other current_schemas result? If the *only* difference >> is whether you use --host=localhost or not, it's hard to conclude >> anything but that you're connecting to two different databases. >> I don't quite see how that could be, with only one postmaster on >> the machine, but maybe it's time to wonder about rogue connection >> poolers or the like. > > specifying the connection host does not change the observed behaviours. > >> >> It might be worth poking into the pg_db_role_setting catalog, >> which is the most likely source of a different search_path for >> different connections. > > It seems so: > > idempiere=# SELECT * FROM pg_db_role_setting; > setdatabase | setrole | setconfig > -------------+---------+--------------------------------------- > 0 | 21328 | {"search_path=adempiere, pg_catalog"} To confirm what role this is assigned to do: select rolname from pg_authid where oid = 21328; > (1 row) > >> >> Another line of thought is maybe you have a ~/.psqlrc that's >> altering the search_path setting. >> > > Up until 5 minutes ago I did not have a ~/.psqlrc file. And there is no system > psqlrc file. > > -- Adrian Klaver adrian.klaver@aklaver.com
pgsql-general by date: