Re: Cursor fetch Problem. - Mailing list pgsql-general

From Amit Kapila
Subject Re: Cursor fetch Problem.
Date
Msg-id 001101cde409$0d22b770$27682650$@kapila@huawei.com
Whole thread Raw
In response to Re: Cursor fetch Problem.  (Harry <shirlekar.harshal@gmail.com>)
Responses Re: Cursor fetch Problem.  (Harry <shirlekar.harshal@gmail.com>)
List pgsql-general
On Thursday, December 27, 2012 11:51 AM Harry wrote:
> Hi Amit,
> Thanks for Reply.
> Kindly see my below output.
> 16650;"sampledb";11965;10;"enterprisedb";"";"192.168.0.231";"";53897;"*
> 2012-12-19
> 11:39:48.234799+05:30";"2012-12-19 11:39:53.288441+05:30";"2012-12-19
> 11:39:53.288441+05:30*";f;"DECLARE
> BEGIN
> EXEC
> 16650;"sampledb";12156;10;"enterprisedb";"";"192.168.0.231";"";53983;*"
> 2012-12-19
> 12:18:38.57709+05:30";"2012-12-19 12:18:43.922301+05:30";"2012-12-19
> 12:18:43.922301+05:30"*;f;"DECLARE
> BEGIN
> EXEC
> 16650;"sampledb";13243;10;"enterprisedb";"Postgres Studio -
> Browser";"192.168.0.180";"";3907;"2012-12-26
> 16:35:45.753172+05:30";"";"2012-12-26 16:35:46.577723+05:30";f;"<IDLE>"

Above shows that first two sessions are running from last few days.
I am interested to know what is the transaction state in first 2 sessions.
In current version that information is part of pg_stat_activity, but don't
know how to get in the version you are using.
If possible for you, get this information. If you are using Linux system the
try ps ax | grep postgres and show the output


> Also, tried to Kill it Firstly by using Cancel Backend and then
> Terminate
> Backend output showing "True" but still remaining as a process (i.e. in
> pg_stat_activity).

Are you aware whether there is actually such long query running in first 2
sessions.
If you are not interested in first 2 sessions, you can even use OS kill
command.

With Regards,
Amit Kapila.



pgsql-general by date:

Previous
From: Harry
Date:
Subject: Re: Cursor fetch Problem.
Next
From: Amit Kapila
Date:
Subject: Re: Cursor fetch Problem.