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 c
On Fri, Jul 24, 2009 at 11:15 AM, Tom Lane wrote:
> Robert Haas 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 state
Robert Haas 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 appropriate timestamp
Robert Haas 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 appropriate timesta
On Fri, Jul 24, 2009 at 10:47 AM, Kevin
Grittner wrote:
> daveg 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'
daveg 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. Possibly
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 in transaction designation and the query
> string into the same database column. I've never liked having to
> write:
>
> select sum(1) from pg_
On Thu, Jun 4, 2009 at 9:54 PM, Tatsuhito
Kasahara wrote:
> Kevin Grittner wrote:
>>
>> Greg Stark 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.
>>
>
Kevin Grittner wrote:
Greg Stark 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
+1
# And I'
Greg Stark 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
--
Sent via pgsql-
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:
http://www
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= in transaction
Currently i have no idea what exactly did i kill without digg
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 to
(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 betwe
On Fri, Mar 27, 2009 at 8:27 AM, Guillaume Smet
wrote:
> 2009/3/27 Tatsuhito Kasahara :
>> 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
On Fri, Mar 27, 2009 at 9:07 AM, Simon Riggs 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 reasons for this probl
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 spe
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.
> "id
2009/3/27 Tatsuhito Kasahara :
> 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.
Considering this usage, +1 for me.
--
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
> >
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
> recen
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
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
Tatsuhito Kasahara 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 extension module using new ex
Guillaume Smet wrote:
On Wed, Mar 25, 2009 at 5:48 PM, hubert depesz lubaczewski
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 trac
On Wed, Mar 25, 2009 at 5:48 PM, hubert depesz lubaczewski
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 lot of idle i
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
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 shou
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 lo
29 matches
Mail list logo
