Thread: "bad key in cancel request"

"bad key in cancel request"

From
Neil Conway
Date:
I noticed that processCancelRequest() emits a log message at DEBUG2 when
it receives a cancel request with a bad key or for a non-existent PID.
For example,
   ereport(DEBUG2,           (errmsg_internal("bad key in cancel request for process %d",            backendPID)));

I think this ought to be logged at a higher level than DEBUG2: for one
thing, it is a potential security issue the DBA might want to be aware
of. It could also indicate a misconfigured or buggy client application.
Therefore, I think we should raise the level to WARNING, or perhaps
NOTICE. Any objections?

-Neil




Re: "bad key in cancel request"

From
Tom Lane
Date:
Neil Conway <neilc@samurai.com> writes:
>     ereport(DEBUG2,
>             (errmsg_internal("bad key in cancel request for process %d",
>              backendPID)));

> I think this ought to be logged at a higher level than DEBUG2: for one
> thing, it is a potential security issue the DBA might want to be aware
> of. It could also indicate a misconfigured or buggy client application.
> Therefore, I think we should raise the level to WARNING, or perhaps
> NOTICE. Any objections?

No, if it's intended for the log it should be LOG.  Your other proposals
are actually *less* likely to get to where the DBA could see them.
        regards, tom lane


Re: "bad key in cancel request"

From
Neil Conway
Date:
On Sun, 2007-11-04 at 11:06 -0500, Tom Lane wrote:
> No, if it's intended for the log it should be LOG.  Your other proposals
> are actually *less* likely to get to where the DBA could see them.

Good point. I suggested WARNING because that suggests that something is
awry, whereas LOG is used for routine log messages.

I've changed the messages from DEBUG2 to LOG in CVS HEAD -- I didn't
backport the change, but I can if anyone feels strongly about it.

-Neil