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
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 changing this
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.
Anybody have
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. A
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 other
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
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, we
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:
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 ID?
A
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.
---
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
11 matches
Mail list logo
