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
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
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
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
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.
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
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.
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 |
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
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,
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
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
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
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.
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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.
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)
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));
>
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
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
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
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)
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
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
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
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
>
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
40 matches
Mail list logo