Re: [PROPOSAL] Client Log Output Filtering - Mailing list pgsql-hackers

From David Steele
Subject Re: [PROPOSAL] Client Log Output Filtering
Date
Msg-id 57028EFE.9070402@pgmasters.net
Whole thread Raw
In response to Re: [PROPOSAL] Client Log Output Filtering  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PROPOSAL] Client Log Output Filtering  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 4/4/16 11:21 AM, Tom Lane wrote:
> David Steele <david@pgmasters.net> writes:
>> On 3/29/16 12:58 PM, Tom Lane wrote:
>>> ...  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.
>
> Uh, what?  COMMERROR is a distinct concept in my opinion.  It might happen
> to share the same implementation today, but that doesn't make it the
> same thing.

Fair enough.

> I had in mind a patch that simply added LOG_SERVER_ONLY as another define
> and did whatever seemed appropriate documentation-wise.  I see no reason
> to touch the places that are currently dealing with client communication
> failures.

I still prefer to collapse them into a single value for the current
implementation.  Otherwise there are several places that need to check
for both in elog.c and their behavior is identical (for now).  For my 2c
it makes more sense to collapse COMMERROR into LOG_SERVER_ONLY since
that more accurately describes what it actually does in the elog code.

What do you think of the attached?

COMMERROR was not documented in sources.sgml so LOG_SERVER_ONLY wasn't
either.  I'm happy to do that that though it's not clear to me where it
would go.  I could just put it in the general description.

Thanks,
--
-David
david@pgmasters.net

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: SSL indicator in psql prompt
Next
From: Aleksander Alekseev
Date:
Subject: Yet another small patch - reorderbuffer.c:1099