Re: [PROPOSAL] Client Log Output Filtering
От | David Steele |
---|---|
Тема | Re: [PROPOSAL] Client Log Output Filtering |
Дата | |
Msg-id | 57028EFE.9070402@pgmasters.net обсуждение исходный текст |
Ответ на | Re: [PROPOSAL] Client Log Output Filtering (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PROPOSAL] Client Log Output Filtering
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: