Re: [PROPOSAL] Client Log Output Filtering

From: David Steele <david(at)pgmasters(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PROPOSAL] Client Log Output Filtering
Date: 2016-04-04 15:17:11
Message-ID: 57028577.1030308@pgmasters.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Tom,

On 3/29/16 12:58 PM, Tom Lane wrote:

> Oh, I agree that there's a compelling use-case for LOG |
> ERR_HIDE_FROM_CLIENT. I'm less certain that there's a use-case
> for supporting such a flag across all elevels that is strong enough
> to justify all the work we'd have to do to make it happen. Basically,
> my point is that LOG_ONLY achieves 95% of the benefit for probably
> 0.01% of the work.

Attached is a patch that re-purposes COMMERROR as LOG_SERVER_ONLY. I
went ahead and replaced all instances of COMMERROR with LOG_SERVER_ONLY.

I left the COMMERROR #define but it is no longer used by any server,
client, or included contrib code (I also noted that it was DEPRECATED in
the comment). I'll leave it up to the committer to remove if deemed
appropriate.

I realize there's no agreement on how this should work ideally, but this
patch answers the current need without introducing anything new and
shouldn't cause regressions. It does address confusion that would arise
from using COMMERROR in ereports that clearly are not.

Thanks,
--
-David
david(at)pgmasters(dot)net

Attachment Content-Type Size
ereport-v4.patch text/plain 14.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Aleksander Alekseev 2016-04-04 15:19:46 Re: Tiny patch: sigmask.diff
Previous Message Andres Freund 2016-04-04 15:15:29 Re: Timeline following for logical slots