| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, David Steele <david(at)pgmasters(dot)net>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PROPOSAL] Client Log Output Filtering |
| Date: | 2016-03-29 16:38:48 |
| Message-ID: | 14906.1459269528@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2016-03-29 12:28:40 -0400, Tom Lane wrote:
>> My proposal would be to invent a new elevel macro, maybe LOG_ONLY,
>> for this purpose. But under the hood it'd be the same as COMMERROR.
> A couple years back I proposed making thinks like COMERROR into flags |
> ed into elevel, rather than distinct levels. I still think that's a
> better approach; and it doesn't force us to forgo using distinct log
> levels.
If we invent LOG_ONLY (feel free to bikeshed the name), we could later
redefine it as (LOG | ERR_HIDE_FROM_CLIENT), if we ever upgrade the
underlying implementation to allow that. But I remain concerned about
dealing with logic like "if (elevel < ERROR)", and I am unconvinced that
there's a near-term use-case here that's compelling enough to justify
finding all the places that do that.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Magnus Hagander | 2016-03-29 16:40:40 | Re: Updated backup APIs for non-exclusive backups |
| Previous Message | Alexander Korotkov | 2016-03-29 16:37:18 | Re: PoC: Partial sort |