On Friday 24 July 2009 18:15:00 Tom Lane wrote:
Another question is that this proposal effectively redefines the
current_query column as not the current query, but something that
might be better be described as latest_query. Should we change the
name? We'd probably break some client code if
daveg da...@sonic.net wrote:
On Thu, Jun 04, 2009 at 10:22:41PM -0400, Robert Haas wrote:
maybe make a separate column called idle that's a boolean,
or something, and let the query column contain the most recent
query (whether or not it's still executing).
+1
I like this idea a lot.
On Fri, Jul 24, 2009 at 10:47 AM, Kevin
Grittnerkevin.gritt...@wicourts.gov wrote:
daveg da...@sonic.net wrote:
On Thu, Jun 04, 2009 at 10:22:41PM -0400, Robert Haas wrote:
maybe make a separate column called idle that's a boolean,
or something, and let the query column contain the most
Robert Haas robertmh...@gmail.com wrote:
Hmm, I don't think we'd need two columns for this, actually. You
could just have one column last_statement_endtime (not sure if it's
the best name, but something along those lines) which would be NULL
if the statement was still in progress and the
Robert Haas robertmh...@gmail.com writes:
Hmm, I don't think we'd need two columns for this, actually. You
could just have one column last_statement_endtime (not sure if it's
the best name, but something along those lines) which would be NULL if
the statement was still in progress and the
On Fri, Jul 24, 2009 at 11:15 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Hmm, I don't think we'd need two columns for this, actually. You
could just have one column last_statement_endtime (not sure if it's
the best name, but something along those lines)
On Thu, Jun 04, 2009 at 10:22:41PM -0400, Robert Haas wrote:
The only thing I don't like about this is that I think it's kind of a
hack to shove the IDLE in transaction designation and the query
string into the same database column. I've never liked having to
write:
select sum(1) from
Kevin Grittner wrote:
Greg Stark st...@enterprisedb.com wrote:
Should this patch be on the commitfest page for 8.5? Or is there a
consensus already that it's a bad idea?
Personally I actually think this makes a lot of sense to do.
+1
It at least gives one a reasonable chance to get a
On Thu, Jun 4, 2009 at 9:54 PM, Tatsuhito
Kasaharakasahara.tatsuh...@oss.ntt.co.jp wrote:
Kevin Grittner wrote:
Greg Stark st...@enterprisedb.com wrote:
Should this patch be on the commitfest page for 8.5? Or is there a
consensus already that it's a bad idea?
Personally I actually think
Should this patch be on the commitfest page for 8.5? Or is there a
consensus already that it's a bad idea?
Personally I actually think this makes a lot of sense to do.
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Greg Stark st...@enterprisedb.com wrote:
Should this patch be on the commitfest page for 8.5? Or is there a
consensus already that it's a bad idea?
Personally I actually think this makes a lot of sense to do.
+1
It at least gives one a reasonable chance to get a useful clue
-Kevin
After taking look at our monitoring system i think some hint about previous
SQL might be useful.
dbadb70db_nameWARNING1long transactions, duration
2690min user=postgres pid=7887 waiting=False query=IDLE in transaction
Currently i have no idea what exactly did i kill without
On Mar 27, 2009, at 2:36 AM, Simon Riggs wrote:
Not really. I want to understand the actual problem with
idle-in-transaction so we can consider all ways to solve it, rather
than
just focus on one method.
I have to distinct problems with idle in transaction. One is
reporting users / the
(Sorry for delay..)
Guillaume Smet wrote:
Being able to detect which application is running which query on the
very same database with the very same user seems like something not so
obvious and the use case seems to be pretty narrow. And IMHO, even if
we suppose you can make the difference
Simon Riggs wrote:
If we can also check previous query_string of idle-in-transaction,
it is useful for analysis of long transaction problem.
I'm more interested in the problem itself. Why do you think there is a
problem and why does knowing this help you? I had similar problems
recently, so
On Fri, 2009-03-27 at 15:44 +0900, Tatsuhito Kasahara wrote:
Simon Riggs wrote:
If we can also check previous query_string of idle-in-transaction,
it is useful for analysis of long transaction problem.
I'm more interested in the problem itself. Why do you think there is a
problem and
2009/3/27 Tatsuhito Kasahara kasahara.tatsuh...@oss.ntt.co.jp:
But if I can also check last query string, I guess which apllication
do that and point out the problem point.
Oh, I just understand why you want this patch. I usually have one
database per server so I didn't see your point.
On Fri, 2009-03-27 at 16:49 +0900, Tatsuhito Kasahara wrote:
Simon Riggs wrote:
Does that answer your question ?
Not really. I want to understand the actual problem with
idle-in-transaction so we can consider all ways to solve it, rather than
just focus on one method.
idle in
Simon Riggs wrote:
Does that answer your question ?
Not really. I want to understand the actual problem with
idle-in-transaction so we can consider all ways to solve it, rather than
just focus on one method.
idle in transaction timeout feature may be one of the ways.
But I have no specific
On Fri, Mar 27, 2009 at 9:07 AM, Simon Riggs si...@2ndquadrant.com wrote:
Or take it further back still and think about why idle in transaction
occurs at all and fix *that*. Maybe not in Postgres at all, possibly in
the driver or even higher up client stack.
From my experience, the main
On Fri, Mar 27, 2009 at 8:27 AM, Guillaume Smet
guillaume.s...@gmail.com wrote:
2009/3/27 Tatsuhito Kasahara kasahara.tatsuh...@oss.ntt.co.jp:
But if I can also check last query string, I guess which apllication
do that and point out the problem point.
Oh, I just understand why you want this
Guillaume Smet wrote:
On Wed, Mar 25, 2009 at 5:48 PM, hubert depesz lubaczewski
dep...@depesz.com wrote:
I would love to get it, but when I suggested it some time in the past
Tom shot it down as bad idea.
http://archives.postgresql.org/message-id/20071016132131.ga4...@depesz.com
I agree
Tatsuhito Kasahara kasahara.tatsuh...@oss.ntt.co.jp wrote:
So, main purpose of displaying the last query string is ..
- check whether idle in transaction (running long time) process
after SOME SQL is exists or not.
- check the content of SOME SQL.
The feature could be achieved by an
ITAGAKI Takahiro wrote:
The feature could be achieved by an extension module using new executor
hooks in 8.4. It is just like contrib/pg_stat_statements;
Well, it is a good idea.
Displaying last-query-string may be useful, but it is not a feature for
general purpose. So, it may be an external
On Wed, 2009-03-25 at 18:08 +0900, Tatsuhito Kasahara wrote:
If we can also check previous query_string of idle-in-transaction,
it is useful for analysis of long transaction problem.
I'm more interested in the problem itself. Why do you think there is a
problem and why does knowing this help
Hi.
Now, we can check the running query string by pg_stat_activity.current_query.
If we can also check previous query_string of idle-in-transaction,
it is useful for analysis of long transaction problem.
Long-transaction is a trouble, because it prevents defragmentation of HOT and
VACUUM.
And
This sure is a desirable feature. I have seen quite a few instances, where
the app is in 'IDLE in Transaction' state, and we are left with the only
choice of killing such processes from OS. (Remember pg_cancel_backend() does
not work for sessions in IDLE or IDLE in transaction state)
Also, it
On Wed, Mar 25, 2009 at 06:08:43PM +0900, Tatsuhito Kasahara wrote:
So, I sometimes want to know what query (main cause) was done before
transaction which have been practiced for a long time.
Thoughts?
I would love to get it, but when I suggested it some time in the past
Tom shot it down as
On Wed, Mar 25, 2009 at 5:48 PM, hubert depesz lubaczewski
dep...@depesz.com wrote:
I would love to get it, but when I suggested it some time in the past
Tom shot it down as bad idea.
http://archives.postgresql.org/message-id/20071016132131.ga4...@depesz.com
I agree with Tom here. I tracked a
29 matches
Mail list logo
