Re: invalid search_path complaints

On Tue, Apr 3, 2012 at 2:16 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Apr 3, 2012 at 12:05 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> On Tue, Apr 3, 2012 at 11:49 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>> I would say that's an improvement.  Do you think it isn't?
>
>>> It seems like a log spam hazard at high connection rates.
>
> [ shrug... ]  Failing to report a problem is a problem, too.  By your
> argument any error message anywhere should be removed because it might
> be a "log spam hazard" at high reporting rates.

That seems rather reductio ad absurdum. I mean, any error message
will repeat if the underlying condition repeats: for example, if there
are many attempts to read bad blocks from the disk, then you will get
many read errors. But in this case, you get many errors even though
nothing new has happened, which as I understand is something we try to
avoid. For example, when we deprecated the use of => as an operator
name, there was some confusion over whether we were going to warn when
the operator was defined or when it was used, and there was universal
consensus in favor of warning only about the former:

http://archives.postgresql.org/pgsql-hackers/2010-06/msg00493.php

So we have an established precedent that it is right to warn about
things that are sketchy at the time that they are defined, but not
every time they are used.

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