From: | Jeff Frost <jeff(at)pgexperts(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #15299: relation does not exist errors |
Date: | 2018-07-26 19:05:55 |
Message-ID: | F8F8913D-3491-471A-A9D6-4C36CE9F786D@pgexperts.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
> On Jul 26, 2018, at 9:50 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> =?utf-8?q?PG_Bug_reporting_form?= <noreply(at)postgresql(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-07-26 19:14:35 | Re: BUG #15299: relation does not exist errors |
Previous Message | Tom Lane | 2018-07-26 18:47:20 | Re: BUG #15300: "do you want the application "postgres" to accept incoming network connections" dialog box madness |