Re: BUG #15299: relation does not exist errors
От | Jeff Frost |
---|---|
Тема | Re: BUG #15299: relation does not exist errors |
Дата | |
Msg-id | 67DE56DF-0DA6-48B6-9FC1-608AE5462D58@pgexperts.com обсуждение исходный текст |
Ответ на | Re: BUG #15299: relation does not exist errors (Jeff Frost <jeff@pgexperts.com>) |
Список | pgsql-bugs |
> On Jul 26, 2018, at 1:53 PM, Jeff Frost <jeff@pgexperts.com> wrote: > > On Jul 26, 2018, at 1:23 PM, Andres Freund <andres@anarazel.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'recomplete 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 bedoing 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 dumpand upon completion, that connection is returned to the pool as a big fat boobytrap for the next application connection.
В списке pgsql-bugs по дате отправления: