Re: BUG #15299: relation does not exist errors

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.

In response to

Browse pgsql-bugs by date

  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