<p>please have a look at this Q&amp;A I posted some time ago:
<a href="https://craftcms.stackexchange.com/questions/38405/why-do-postgres-schemas-different-from-public-sometimes-not-work-with-craft-d">Why do Postgres schemas different from &quot;public&quot; sometimes not work with Craft (DDEV / Nitro)</a></p>
<p>This will very likely explain the behavior you describe and the know-how is essential when working with postgres.</p>

CC BY-SA 4.0
2022-12-17T13:04:42.727Z
Thanks so much for posting this, it's the info I was looking for - I had attempted updating the search path before dropping everything and putting it into public schema but didn't have success with it at first.  Yii2's inability to prefix objects with the schema is what I concluded after my own journey down the rabbit hole, I'll try the search path again though as using a custom schema in production is the plan. Thanks again!
Rich D.
CC BY-SA 4.0
2022-12-17T13:05:52.887Z
Note: the strangest part was the ./craft cmd managing to resolve everything fine, without any mods - I haven't gotten to the bottom of why that was.
Rich D.
CC BY-SA 4.0
2022-12-19T12:26:18.210Z
I guess it was the same user, right? then it's weird...
Matthias Redl-Mann
CC BY-SA 4.0
2022-12-17T09:08:31.480Z
2022-12-17T09:08:31.480Z
Matthias Redl-Mann
<p>Seems I've sorted it by restoring the pg dump to the default public schema instead of a custom one. Something wasn't referencing the schema when exec'ing queries - even though the db connection was fine (within php-fpm) and from ./craft cmd, both referencing the same DB_ env vars. Didn't dig much deeper but attempted an install using the craft cmd which got so far then a plugin ran into the same issue above, need to see exactly where/why it's happening but that's one to inspect at a later date.</p>

CC BY-SA 4.0
2022-12-16T23:20:48.087Z
2022-12-16T23:44:23.810Z
2022-12-16T23:44:23.810Z
Rich D.
<p>I'm having a strange issue when accessing a craft instance via the web yet the craft cmd works fine.  When resolving the URL it's throwing a 503 and the logs are showing an issue with fetching data from the info table, stating the relation doesn't exit, it seems the db schema env var isn't being picked up/or being used?</p>
<p>Error is:</p>
<pre><code>2022-12-16 18:21:56 [web.INFO] [yii\db\Connection::open] Opening DB connection: pgsql:host=xxx;dbname=xxx;port=5432 {&quot;memory&quot;:2025488} 
2022-12-16 18:21:56 [web.ERROR] [craft\base\ApplicationTrait::getIsInstalled] There was a problem fetching the info row: SQLSTATE[42P01]: Undefined table: 7 ERR
OR:  relation &quot;info&quot; does not exist
LINE 2: FROM &quot;info&quot;
             ^
The SQL being executed was: SELECT *
FROM &quot;info&quot;
WHERE &quot;id&quot;=1
LIMIT 1 {&quot;memory&quot;:2313616}
</code></pre>
<p>The env vars are all in place:</p>
<pre><code># printenv | grep DB_
DB_PASSWORD=xxx
DB_PORT=5432
DB_USER=xxx
DB_SCHEMA=xxx
DB_SERVER=xxx
DB_DRIVER=pgsql
DB_DATABASE=xxx
</code></pre>
<p>And running the install/check cmd reports craft is installed fine.</p>
<pre><code># ./craft install/check
Craft is installed.
</code></pre>
<p>Any ideas? Any help appreciated!</p>

<error-message><install><craft4><postgresql>
Postgres DB Schema not referenced when accessing web url but craft cmd works fine?
# Postgres DB Schema not referenced when accessing web url but craft cmd works fine?

(Asked by: username_0 on 2022-12-16)

I'm having a strange issue when accessing a craft instance via the web yet the craft cmd works fine.  When resolving the URL it's throwing a 503 and the logs are showing an issue with fetching data from the info table, stating the relation doesn't exit, it seems the db schema env var isn't being picked up/or being used?
Error is:
2022-12-16 18:21:56 [web.INFO] [yii\db\Connection::open] Opening DB connection: pgsql:host=xxx;dbname=xxx;port=5432 {"memory":2025488} 
2022-12-16 18:21:56 [web.ERROR] [craft\base\ApplicationTrait::getIsInstalled] There was a problem fetching the info row: SQLSTATE[42P01]: Undefined table: 7 ERR
OR:  relation "info" does not exist
LINE 2: FROM "info"
             ^
The SQL being executed was: SELECT *
FROM "info"
WHERE "id"=1
LIMIT 1 {"memory":2313616}

The env vars are all in place:
# printenv | grep DB_
DB_PASSWORD=xxx
DB_PORT=5432
DB_USER=xxx
DB_SCHEMA=xxx
DB_SERVER=xxx
DB_DRIVER=pgsql
DB_DATABASE=xxx

And running the install/check cmd reports craft is installed fine.
# ./craft install/check
Craft is installed.

Any ideas? Any help appreciated!

**Tags:** error-message, install, craft4, postgresql

---

## 2 answers

### Answer by username_1 on 2022-12-17. Score: 2 | Accepted answer

please have a look at this Q&A I posted some time ago:
[Why do Postgres schemas different from "public" sometimes not work with Craft (DDEV / Nitro)](https://craftcms.stackexchange.com/questions/38405/why-do-postgres-schemas-different-from-public-sometimes-not-work-with-craft-d)

This will very likely explain the behavior you describe and the know-how is essential when working with postgres.

> **Comments:**
> **username_0**: Thanks so much for posting this, it's the info I was looking for - I had attempted updating the search path before dropping everything and putting it into public schema but didn't have success with it at first.  Yii2's inability to prefix objects with the schema is what I concluded after my own journey down the rabbit hole, I'll try the search path again though as using a custom schema in production is the plan. Thanks again!  
> **username_0**: Note: the strangest part was the ./craft cmd managing to resolve everything fine, without any mods - I haven't gotten to the bottom of why that was.  
> **username_1**: I guess it was the same user, right? then it's weird...  

---

### Answer by username_0 on 2022-12-16. Score: 1

Seems I've sorted it by restoring the pg dump to the default public schema instead of a custom one. Something wasn't referencing the schema when exec'ing queries - even though the db connection was fine (within php-fpm) and from ./craft cmd, both referencing the same DB\_ env vars. Didn't dig much deeper but attempted an install using the craft cmd which got so far then a plugin ran into the same issue above, need to see exactly where/why it's happening but that's one to inspect at a later date.


---

