Re: invalid search_path complaints - Mailing list pgsql-hackers

From Robert Haas
Subject Re: invalid search_path complaints
Date
Msg-id CA+TgmoYor84qQzo1wWGyCAvpwsGjm-8k=6TYywX9Y8vi1jRvAQ@mail.gmail.com
Whole thread Raw
In response to Re: invalid search_path complaints  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: invalid search_path complaints  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, Apr 3, 2012 at 11:49 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> If you use ALTER ROLE/DATABASE SET to configure an invalid
>> search_path, PostgreSQL 9.1 issues a complaint about the invalid
>> setting on each new connection.  This is a behavior change relatively
>> to previous releases, which did not.
>
> I would say that's an improvement.  Do you think it isn't?

It seems like a log spam hazard at high connection rates.

> The real issue I think is not so much whether a warning appears, as
> that prior releases actually installed the broken search_path value
> as active, which seems worse than leaving the default in place.

I don't have enough experience with broken search_path settings to
have a very certain opinion on this part one way or the other.
Generally I try not to run with broken configurations in the first
place, but it obviously does happen in real life.

But, trying to speculate... if your search path is busted because one
constituent schema has dropped and all the others are still there, you
might still want to still search the remaining schemas.  If your
search path is going to end up being completely empty, then you might
prefer to get whatever the underlying default is... or you might not.
Did you get the wrong search_path because it should have been set
per-user-and-database and was instead set per-user?  Or did you get
the wrong search_path because you connected to a database that wasn't
the one you intended to connect to?  I'm not sure there's a right
answer in this case.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: patch for parallel pg_dump
Next
From: Robert Haas
Date:
Subject: Re: patch for parallel pg_dump