From: | Jeff Frost <jeff(at)pgexperts(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #15299: relation does not exist errors |
Date: | 2018-08-20 01:48:14 |
Message-ID: | 67DE56DF-0DA6-48B6-9FC1-608AE5462D58@pgexperts.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
> On Jul 26, 2018, at 1:53 PM, Jeff Frost <jeff(at)pgexperts(dot)com> wrote:
>
> On Jul 26, 2018, at 1:23 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>>
>> On 2018-07-26 13:18:33 -0700, Jeff Frost wrote:
>>> Oh, I see what you're saying. Don't the autovacuum processes connect to their own backends which then exit after they're complete though?
>>
>> Yes, that's right. Creating an extension or calling a function that
>> internally does a SET search_path seem like a more likely cause.
>
> I grepped our code and didn't find anywhere that we set search_path, though it's possible some ruby gem we use could be doing it. I'll go spelunking there next!
Wanted to close the loop on this. As usual, Tom was right.
We have a rake task in the application used to pull a production copy of structure.sql which uses pg_dump under the covers. Because it uses the same conninfo as the app, it happily goes through pgbouncer. So, when that rake task is run, pg_dump connects through pgbouncer and happily sets that restrictive search_path. It then creates the schema-only dump and upon completion, that connection is returned to the pool as a big fat boobytrap for the next application connection.
From | Date | Subject | |
---|---|---|---|
Next Message | Kai Kratz | 2018-08-20 05:22:25 | Re: BUG #15327: postgres segfaults on ALTER FUNCTION ... SET SCHEMA ... |
Previous Message | Amit Langote | 2018-08-20 01:00:46 | Re: BUG #15334: Partition elimination not working as expected when using enum as partition key |