Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

On 4/4/16 12:36 PM, Tom Lane wrote: David Steele writes: On 4/4/16 11:21 AM, Tom Lane wrote: 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

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

David Steele writes: > On 4/4/16 11:21 AM, Tom Lane wrote: >> 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

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

On 4/4/16 11:21 AM, Tom Lane wrote: David Steele 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

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

David Steele 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

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

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.

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

Andres Freund writes: > There's a number of cases during early startup/auth where we really > don't want client to get messages. Right, which we handle at present with ClientAuthInProgress. But I think it's worth drawing a distinction between "don't send message to client

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

On 2016-03-29 12:58:22 -0400, Tom Lane wrote: > Looking back at the earlier thread Andres mentioned, I see that he was > specifically on about being able to do ereport(ERROR | LOG_NO_CLIENT), > which I've got a problem with because of the point about not breaking > wire-protocol expectations.

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

On Tue, Mar 29, 2016 at 12:58 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Mar 29, 2016 at 12:38 PM, Tom Lane wrote: >>> If we invent LOG_ONLY (feel free to bikeshed the name), we could later >>> redefine it as (LOG |

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

Robert Haas writes: > On Tue, Mar 29, 2016 at 12:38 PM, Tom Lane wrote: >> 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

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

Robert Haas wrote: > Yeah, I think it's dead certain that such code exists, and, ahem, not > only in our tree. I suspect that EDB is not the only organization > that has written code that involves comparing error levels. Putting > the flags in the low-order bits seems like it might be workable,

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

On Tue, Mar 29, 2016 at 12:38 PM, Tom Lane wrote: > Andres Freund 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

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

On 2016-03-29 12:38:48 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2016-03-29 12:28:40 -0400, Tom Lane wrote: > 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

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

Andres Freund 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

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

On 2016-03-29 18:33:19 +0200, Andres Freund wrote: > 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.

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

On 2016-03-29 12:28:40 -0400, Tom Lane wrote: > Alvaro Herrera writes: > > David Steele wrote: > >> On 3/29/16 10:18 AM, Tom Lane wrote: > >>> Repurposing COMMERROR is definitely starting to seem like a low-impact > >>> solution compared to these others. Under what

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

On 3/29/16 12:28 PM, Tom Lane wrote: Alvaro Herrera writes: David Steele wrote: On 3/29/16 10:18 AM, Tom Lane wrote: Repurposing COMMERROR is definitely starting to seem like a low-impact solution compared to these others. Under what circumstances would you be

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

Alvaro Herrera writes: > David Steele wrote: >> On 3/29/16 10:18 AM, Tom Lane wrote: >>> Repurposing COMMERROR is definitely starting to seem like a low-impact >>> solution compared to these others. Under what circumstances would you >>> be wanting hide-from-client with

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

On 3/29/16 11:37 AM, Alvaro Herrera wrote: David Steele wrote: On 3/29/16 10:18 AM, Tom Lane wrote: Repurposing COMMERROR is definitely starting to seem like a low-impact solution compared to these others. Under what circumstances would you be wanting hide-from-client with an elevel

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

David Steele wrote: > On 3/29/16 10:18 AM, Tom Lane wrote: > >Repurposing COMMERROR is definitely starting to seem like a low-impact > >solution compared to these others. Under what circumstances would you > >be wanting hide-from-client with an elevel different from LOG, anyway? > > In pgaudit

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

On 3/29/16 10:18 AM, Tom Lane wrote: David Steele writes: On 3/28/16 2:00 PM, Tom Lane wrote: One idea is to invent a new elevel which is never sent to the client --- analogously to COMMERROR, though probably much higher priority than that, maybe the same priority as LOG.

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

David Steele writes: > On 3/28/16 2:00 PM, Tom Lane wrote: >> One idea is to invent a new elevel which is never sent to the client --- >> analogously to COMMERROR, though probably much higher priority than that, >> maybe the same priority as LOG. If there actually is a use

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

On 3/28/16 2:00 PM, Tom Lane wrote: I set to work on committing this, but was soon rather dissatisfied with it, because as-implemented there is no way to short-circuit elog.c's processing if the message is not to be sent to either the client or the postmaster log. Ideally this would be taken

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

David Steele writes: > On 3/10/16 11:00 AM, Petr Jelinek wrote: >> The comment above errhidefromclient says "Only log levels below ERROR >> can be hidden from the client." but use of the errhidefromclient(true) >> actually does hide the error message from client, client just

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

On 3/10/16 9:51 AM, Tom Lane wrote: > The patch is evidently modeled on errhidestmt and errhidectx, which are > making the same assumption for their fields. > > I wonder whether, instead of continuing to proliferate random bool fields > in struct ErrorData, we oughta replace them all with an

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

On 3/10/16 11:07 AM, Tom Lane wrote: > Petr Jelinek writes: >> The comment above errhidefromclient says "Only log levels below ERROR >> can be hidden from the client." but use of the errhidefromclient(true) >> actually does hide the error message from client, client just

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

On 3/10/16 11:00 AM, Petr Jelinek wrote: > The comment above errhidefromclient says "Only log levels below ERROR > can be hidden from the client." but use of the errhidefromclient(true) > actually does hide the error message from client, client just gets > failed query without any message when

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

On 10/03/16 17:07, Tom Lane wrote: Petr Jelinek writes: The comment above errhidefromclient says "Only log levels below ERROR can be hidden from the client." but use of the errhidefromclient(true) actually does hide the error message from client, client just gets failed

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

Petr Jelinek writes: > The comment above errhidefromclient says "Only log levels below ERROR > can be hidden from the client." but use of the errhidefromclient(true) > actually does hide the error message from client, client just gets > failed query without any message

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

On 10/03/16 15:08, David Steele wrote: Looking at the code, this adds bool hide_from_client to edata which is not initialized in errstart so that needs to be fixed. I figured this would take care of it: MemSet(edata, 0, sizeof(ErrorData)); Since I want hide_from_client to default to false.

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

David Steele writes: > I have attached a patch that adds an ereport() macro to suppress client > output for a single report call (applies cleanly on 1d0c3b3). I'll also > move it to the next CF. This patch fails to add the necessary documentation (see sources.sgml)

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

David Steele writes: > On 3/9/16 7:37 PM, Petr Jelinek wrote: >> Looking at the code, this adds bool hide_from_client to edata which is >> not initialized in errstart so that needs to be fixed. > I figured this would take care of it: > MemSet(edata, 0, sizeof(ErrorData)); >

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

On 3/9/16 7:37 PM, Petr Jelinek wrote: On 03/02/16 05:02, Robert Haas wrote: On Mon, Feb 1, 2016 at 7:24 PM, David Steele wrote: I have attached a patch that adds an ereport() macro to suppress client output for a single report call (applies cleanly on 1d0c3b3). I'll

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

On 03/02/16 05:02, Robert Haas wrote: On Mon, Feb 1, 2016 at 7:24 PM, David Steele wrote: I have attached a patch that adds an ereport() macro to suppress client output for a single report call (applies cleanly on 1d0c3b3). I'll also move it to the next CF. I don't see

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

On Mon, Feb 1, 2016 at 7:24 PM, David Steele wrote: > On 2/1/16 5:25 PM, Alvaro Herrera wrote: >> David Steele wrote: > >>> 2) There would be two different ways to suppress client messages but I was >>> hoping to only have one. >> >> I think they are two different things

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

David Steele wrote: > On 1/11/16 6:50 PM, Alvaro Herrera wrote: > >David Steele wrote: > >>The patch creates a new counter to separate the log filtering from the > >>authentication functionality. This makes it possible to get the same > >>filtering in other parts of the code (or extensions)

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

On 2/1/16 5:25 PM, Alvaro Herrera wrote: > David Steele wrote: >> 2) There would be two different ways to suppress client messages but I was >> hoping to only have one. > > I think they are two different things actually. Fair enough - that was my initial reaction as well but then I thought the

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

On 1/11/16 6:50 PM, Alvaro Herrera wrote: David Steele wrote: The patch creates a new counter to separate the log filtering from the authentication functionality. This makes it possible to get the same filtering in other parts of the code (or extensions) without abusing the

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

On Mon, Jan 11, 2016 at 6:50 PM, Alvaro Herrera wrote: > I think maybe it's better to have each individual error > message be marked as "don't show to client" rather than a global var. +1. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

David Steele wrote: > Currently log messages generated by pgaudit can be made visible to the > client simply by altering client_min_messages. While this has not been a > showstopper for anyone it's ideal, either. > > The client authentication code sets the global variable ClientAuthInProgress >

[HACKERS] [PROPOSAL] Client Log Output Filtering

Currently log messages generated by pgaudit can be made visible to the client simply by altering client_min_messages. While this has not been a showstopper for anyone it's ideal, either. The client authentication code sets the global variable ClientAuthInProgress which causes ereport() to