On Tue, Apr 3, 2012 at 2:16 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Tue, Apr 3, 2012 at 12:05 PM, Robert Haas <robertmh...@gmail.com> wrote: >>> On Tue, Apr 3, 2012 at 11:49 AM, Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
