Tom Lane schrieb:
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
Here is a patch to log conflicted queries on deadlocks. Queries are dumped
at CONTEXT in the same sorting order as DETAIL messages. Those queries are
picked from pg_stat_get_backend_activity, as same as pg_stat_activity,
so that u
On Sun, Mar 23, 2008 at 3:21 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I wrote:
> > A conservative approach would be to report the query texts *only* in the
> > server log and never to the client --- this would need a bit of klugery
> > but seems doable.
>
> Anybody have any opinions about chang
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I think we should report to the client where it is not a security
> breach, and to the server log otherwise.
Well, the point of my original comment is that it's not always so
obvious what might be a security breach or not.
> I'm not sure about warts.
Tom Lane wrote:
> If we report the query texts only to the server log, we could remove all
> restrictions on which users' queries would be reported. That would
> clearly be helpful in some cases. On the other hand, it would clearly
> be less convenient to use than the existing approach that send
I wrote:
One thing that I worried about for a little bit is that you can imagine
privilege-escalation scenarios.
> A conservative approach would be to report the query texts *only* in the
> server log and never to the client --- this would need a bit of klugery
> but seems doable.
Anybo
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> One thing that I worried about for a little bit is that you can imagine
>> privilege-escalation scenarios.
> Perhaps we should only do this if the current user's ID is the same as the
> outermost session user's I
Gregory Stark <[EMAIL PROTECTED]> writes:
> Ah, reading the patch I see comments indicating that yes that's possible and
> no, we don't really care. So, ok. If the backend disappears entirely could the
> string be empty?
Right, we'd be pointing at a BackendStatusArray entry that was now
unused, or
"Gregory Stark" <[EMAIL PROTECTED]> writes:
> There's no way the other transaction's timeout could fire while we're doing
> this is there? Are we still holding the lw locks at this point which would
> prevent that?
Ah, reading the patch I see comments indicating that yes that's possible and
no, w
"Tom Lane" <[EMAIL PROTECTED]> writes:
> ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
>> Here is a patch to log conflicted queries on deadlocks. Queries are dumped
>> at CONTEXT in the same sorting order as DETAIL messages. Those queries are
>> picked from pg_stat_get_backend_activity, as same as
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> Here is a patch to log conflicted queries on deadlocks. Queries are dumped
> at CONTEXT in the same sorting order as DETAIL messages. Those queries are
> picked from pg_stat_get_backend_activity, as same as pg_stat_activity,
> so that users cannot see
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
IT
Here is a patch to log conflicted queries on deadlocks. Queries are dumped
at CONTEXT in the same sorting order as DETAIL messages. Those queries are
picked from pg_stat_get_backend_activity, as same as pg_stat_activity,
so that users cannot see other user's queries. (It might be better to log
all
12 matches
Mail list logo
