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 currently dealing with cl
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 communication
>> failure
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
went ahead and replaced a
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 instances of COMMERROR
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. B
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 because of the state we
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.
Yes.
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 | ERR_HIDE_FROM_CLIENT), if we ever upgrade the
>>> underlying implement
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 allow that. But I remain concerned about
>> dea
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 COMMERROR.
>
>> A couple years back I pro
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 implementation to allo
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 into flags |
> ed into e
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.
http://archives.postg
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 circumstances would you
> >>> b
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 wanting hide-from-client with a
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 an elevel different from L
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 differen
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 t
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. If there actually is
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 for a range of
>> eleve
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 in
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 gets
>> failed query w
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 "int
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 gets
>> failed query wi
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 use
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 query without any messag
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 when used with ERROR leve
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. A
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)
regar
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));
> Since I want hide_from
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 also
move it to the next
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 any reason not to acc
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 actually.
>
> Fair enough
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 o
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) withou
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
ClientAuthInProgress
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 PostgreSQL Company
--
Sent via
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
> w
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 fil
40 matches
Mail list logo
