On 17 May 2016 at 22:24, Sridhar N Bamandlapally
wrote:
> Hi
>
> I control this way
>
> if "state_change" is from longtime and "state" is idle then I use
>
> function:
> *pg_terminate_backend ( integer ) * ==> return TRUE if
> killed-successful else FALSE
>
> example:
>
Hi
I control this way
if "state_change" is from longtime and "state" is idle then I use
function:
*pg_terminate_backend ( integer ) * ==> return TRUE if killed-successful
else FALSE
example:
# select pg_terminate_backend ( pid ) from pg_stat_activity where
state='idle' and state_change <
On 05/16/2016 02:25 PM, John R Pierce wrote:
On 5/16/2016 2:11 PM, Adrian Klaver wrote:
Yes a connection consumes resources.
an idle connection consumes some memory, a process context, and a
network socket. its not using CPU or disk IO.
True, but the existence of poolers says that can be
On 5/16/2016 2:11 PM, Adrian Klaver wrote:
Yes a connection consumes resources.
an idle connection consumes some memory, a process context, and a
network socket. its not using CPU or disk IO.
True, but the existence of poolers says that can be an issue.
I note that MRTG style graph
On 05/16/2016 02:00 PM, John R Pierce wrote:
On 5/16/2016 1:55 PM, Adrian Klaver wrote:
Would the pool connection solve that IDLE connections? But more
important than that, are the IDLE connections using the machine's
resources ?
Yes a connection consumes resources.
an idle connection
On 17 May 2016 at 08:56, Venkata Balaji N wrote:
>
> On Tue, May 17, 2016 at 6:28 AM, Lucas Possamai
> wrote:
>
>> hmm.. thanks for all the answers guys...
>>
>>
>> One more question: Those IDLE connections.. are using the server's
>> resources?
>> To
On 5/16/2016 1:55 PM, Adrian Klaver wrote:
Would the pool connection solve that IDLE connections? But more
important than that, are the IDLE connections using the machine's
resources ?
Yes a connection consumes resources.
an idle connection consumes some memory, a process context, and a
On Tue, May 17, 2016 at 6:28 AM, Lucas Possamai
wrote:
> hmm.. thanks for all the answers guys...
>
>
> One more question: Those IDLE connections.. are using the server's
> resources?
> To solve that problem I would need a Pool connection, right?
>
> Would the pool
On 05/16/2016 01:28 PM, Lucas Possamai wrote:
hmm.. thanks for all the answers guys...
One more question: Those IDLE connections.. are using the server's
resources?
To solve that problem I would need a Pool connection, right?
Yes and no. If your application/clients are generating connections
hmm.. thanks for all the answers guys...
One more question: Those IDLE connections.. are using the server's
resources?
To solve that problem I would need a Pool connection, right?
Would the pool connection solve that IDLE connections? But more important
than that, are the IDLE connections using
On 05/16/2016 09:56 AM, Charles Clavadetscher wrote:
Hello
On 16.05.2016, at 18:32, Francisco Olarte > wrote:
Hi Lucas
On Mon, May 16, 2016 at 4:10 AM, Lucas Possamai > wrote:
Charles:
On Mon, May 16, 2016 at 6:56 PM, Charles Clavadetscher
wrote:
> There really is a state 'Idle in transaction'? Good to learn.
Again, IIRC, it was there in the graph legend, orange was Idle, yellow
was Idle in transaction ( not in the data, just in the
Hello
> On 16.05.2016, at 18:32, Francisco Olarte wrote:
>
> Hi Lucas
>
>> On Mon, May 16, 2016 at 4:10 AM, Lucas Possamai wrote:
>>
>> Those IDLE connections, might be because the user/application didn't commit
>> the transaction?
>
> IIRC
Hi Lucas
On Mon, May 16, 2016 at 4:10 AM, Lucas Possamai
wrote:
>
> Those IDLE connections, might be because the user/application didn't
> commit the transaction?
>
IIRC Those would be 'Idle in transaction' ( which are normally bad if
numerous, unless your app has a
Hello
> On 16.05.2016, at 04:10, Lucas Possamai wrote:
>
> Hi guys,
>
>
>
> Those IDLE connections, might be because the user/application didn't commit
> the transaction?
I think that idle means that a client is connected but is doing nothing.
Possibly It includes
15 matches
Mail list logo