> On Jul 26, 2018, at 9:50 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> =?utf-8?q?PG_Bug_reporting_form?= <noreply@postgresql.org> writes:
>> We recently upgraded some production servers to 9.5.13 on Saturday
>> (7/21/2018) and they ran fine for 2 days. On Wednesday morning, we started
>> seeing some strange issues where postgres was reporting tons of "relation"
>> does not exist errors. Here are some snippets from the logs:
>
>> 2018-07-25 14:33:53.243
>> GMT,"app_db","webapp",34887,"127.0.0.1:56740",5b587d3b.8847,90363,"PARSE",2018-07-25
>> 13:38:03 GMT,287/3021104,0,ERROR,42P01,"relation ""login_informations"" does
>> not exist",,,
>> ,,,"SELECT ""login_informations"".* FROM ""login_informations"" WHERE
>> ""login_informations"".""id"" = 735211 LIMIT 1",37,,"sidekiq 4.1.2 procore
>> [0 of 5 busy]"
>
>> Connecting to the DB via psql and issuing a \d login_informations showed
>> that the table was there. Running one of the queries from the logs by hand
>> worked fine.
>
> My first thought would be something to do with a restrictive search_path.
Good thought. As far as I can tell we never change it from the default and everything in that DB is in the public
schema.
