Is there a timeout for idle PostgreSQL connections?












69















1 S postgres  5038   876  0  80   0 - 11962 sk_wai 09:57 ?        00:00:00 postgres: postgres my_app ::1(45035) idle                                                                                 
1 S postgres 9796 876 0 80 0 - 11964 sk_wai 11:01 ? 00:00:00 postgres: postgres my_app ::1(43084) idle


I see a lot of them. We are trying to fix our connection leak. But meanwhile, we want to set a timeout for these idle connections, maybe max to 5 minute.










share|improve this question

























  • how are you connecting to the DB? socketTimeout might be what you are looking for.

    – Doon
    Nov 5 '12 at 16:27











  • We have this legacy Pylons web app, and we used SQLAlchemy but apparently we didn't use it properly. I don't remember. We are trying to fix the leak. socketTimeout from the doc it looks like this close the connection to the DB, entirely. I am trying to close each idle, and the counter starts as soon as the connection is established.

    – user1012451
    Nov 5 '12 at 16:32








  • 4





    see stackoverflow.com/questions/12391174/…

    – Doon
    Nov 5 '12 at 16:38











  • @user1012451 When you say "close each idle" - do you mean terminate <IDLE> in transaction sessions, leaving the session running but in <IDLE> state? In other words, terminate the transaction but not the session? (Downvoted: unclear question)

    – Craig Ringer
    Nov 6 '12 at 0:21













  • @CraigRinger after a while, we reach max client connection. To solve that, we must restart the webapp, which forces to restart postgresql as well. That wipe out every connection. When we see these idle forever, we are asking if we could set a timeout on each connection/session (I honestly don't know the correct terminology, sorry). If a transaction takes 5 minutes for a normal web app something must be wrong....

    – user1012451
    Nov 6 '12 at 5:26
















69















1 S postgres  5038   876  0  80   0 - 11962 sk_wai 09:57 ?        00:00:00 postgres: postgres my_app ::1(45035) idle                                                                                 
1 S postgres 9796 876 0 80 0 - 11964 sk_wai 11:01 ? 00:00:00 postgres: postgres my_app ::1(43084) idle


I see a lot of them. We are trying to fix our connection leak. But meanwhile, we want to set a timeout for these idle connections, maybe max to 5 minute.










share|improve this question

























  • how are you connecting to the DB? socketTimeout might be what you are looking for.

    – Doon
    Nov 5 '12 at 16:27











  • We have this legacy Pylons web app, and we used SQLAlchemy but apparently we didn't use it properly. I don't remember. We are trying to fix the leak. socketTimeout from the doc it looks like this close the connection to the DB, entirely. I am trying to close each idle, and the counter starts as soon as the connection is established.

    – user1012451
    Nov 5 '12 at 16:32








  • 4





    see stackoverflow.com/questions/12391174/…

    – Doon
    Nov 5 '12 at 16:38











  • @user1012451 When you say "close each idle" - do you mean terminate <IDLE> in transaction sessions, leaving the session running but in <IDLE> state? In other words, terminate the transaction but not the session? (Downvoted: unclear question)

    – Craig Ringer
    Nov 6 '12 at 0:21













  • @CraigRinger after a while, we reach max client connection. To solve that, we must restart the webapp, which forces to restart postgresql as well. That wipe out every connection. When we see these idle forever, we are asking if we could set a timeout on each connection/session (I honestly don't know the correct terminology, sorry). If a transaction takes 5 minutes for a normal web app something must be wrong....

    – user1012451
    Nov 6 '12 at 5:26














69












69








69


36






1 S postgres  5038   876  0  80   0 - 11962 sk_wai 09:57 ?        00:00:00 postgres: postgres my_app ::1(45035) idle                                                                                 
1 S postgres 9796 876 0 80 0 - 11964 sk_wai 11:01 ? 00:00:00 postgres: postgres my_app ::1(43084) idle


I see a lot of them. We are trying to fix our connection leak. But meanwhile, we want to set a timeout for these idle connections, maybe max to 5 minute.










share|improve this question
















1 S postgres  5038   876  0  80   0 - 11962 sk_wai 09:57 ?        00:00:00 postgres: postgres my_app ::1(45035) idle                                                                                 
1 S postgres 9796 876 0 80 0 - 11964 sk_wai 11:01 ? 00:00:00 postgres: postgres my_app ::1(43084) idle


I see a lot of them. We are trying to fix our connection leak. But meanwhile, we want to set a timeout for these idle connections, maybe max to 5 minute.







postgresql database-connection






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Dec 24 '13 at 1:27









Craig Ringer

197k35401528




197k35401528










asked Nov 5 '12 at 16:24









user1012451user1012451

1,09751929




1,09751929













  • how are you connecting to the DB? socketTimeout might be what you are looking for.

    – Doon
    Nov 5 '12 at 16:27











  • We have this legacy Pylons web app, and we used SQLAlchemy but apparently we didn't use it properly. I don't remember. We are trying to fix the leak. socketTimeout from the doc it looks like this close the connection to the DB, entirely. I am trying to close each idle, and the counter starts as soon as the connection is established.

    – user1012451
    Nov 5 '12 at 16:32








  • 4





    see stackoverflow.com/questions/12391174/…

    – Doon
    Nov 5 '12 at 16:38











  • @user1012451 When you say "close each idle" - do you mean terminate <IDLE> in transaction sessions, leaving the session running but in <IDLE> state? In other words, terminate the transaction but not the session? (Downvoted: unclear question)

    – Craig Ringer
    Nov 6 '12 at 0:21













  • @CraigRinger after a while, we reach max client connection. To solve that, we must restart the webapp, which forces to restart postgresql as well. That wipe out every connection. When we see these idle forever, we are asking if we could set a timeout on each connection/session (I honestly don't know the correct terminology, sorry). If a transaction takes 5 minutes for a normal web app something must be wrong....

    – user1012451
    Nov 6 '12 at 5:26



















  • how are you connecting to the DB? socketTimeout might be what you are looking for.

    – Doon
    Nov 5 '12 at 16:27











  • We have this legacy Pylons web app, and we used SQLAlchemy but apparently we didn't use it properly. I don't remember. We are trying to fix the leak. socketTimeout from the doc it looks like this close the connection to the DB, entirely. I am trying to close each idle, and the counter starts as soon as the connection is established.

    – user1012451
    Nov 5 '12 at 16:32








  • 4





    see stackoverflow.com/questions/12391174/…

    – Doon
    Nov 5 '12 at 16:38











  • @user1012451 When you say "close each idle" - do you mean terminate <IDLE> in transaction sessions, leaving the session running but in <IDLE> state? In other words, terminate the transaction but not the session? (Downvoted: unclear question)

    – Craig Ringer
    Nov 6 '12 at 0:21













  • @CraigRinger after a while, we reach max client connection. To solve that, we must restart the webapp, which forces to restart postgresql as well. That wipe out every connection. When we see these idle forever, we are asking if we could set a timeout on each connection/session (I honestly don't know the correct terminology, sorry). If a transaction takes 5 minutes for a normal web app something must be wrong....

    – user1012451
    Nov 6 '12 at 5:26

















how are you connecting to the DB? socketTimeout might be what you are looking for.

– Doon
Nov 5 '12 at 16:27





how are you connecting to the DB? socketTimeout might be what you are looking for.

– Doon
Nov 5 '12 at 16:27













We have this legacy Pylons web app, and we used SQLAlchemy but apparently we didn't use it properly. I don't remember. We are trying to fix the leak. socketTimeout from the doc it looks like this close the connection to the DB, entirely. I am trying to close each idle, and the counter starts as soon as the connection is established.

– user1012451
Nov 5 '12 at 16:32







We have this legacy Pylons web app, and we used SQLAlchemy but apparently we didn't use it properly. I don't remember. We are trying to fix the leak. socketTimeout from the doc it looks like this close the connection to the DB, entirely. I am trying to close each idle, and the counter starts as soon as the connection is established.

– user1012451
Nov 5 '12 at 16:32






4




4





see stackoverflow.com/questions/12391174/…

– Doon
Nov 5 '12 at 16:38





see stackoverflow.com/questions/12391174/…

– Doon
Nov 5 '12 at 16:38













@user1012451 When you say "close each idle" - do you mean terminate <IDLE> in transaction sessions, leaving the session running but in <IDLE> state? In other words, terminate the transaction but not the session? (Downvoted: unclear question)

– Craig Ringer
Nov 6 '12 at 0:21







@user1012451 When you say "close each idle" - do you mean terminate <IDLE> in transaction sessions, leaving the session running but in <IDLE> state? In other words, terminate the transaction but not the session? (Downvoted: unclear question)

– Craig Ringer
Nov 6 '12 at 0:21















@CraigRinger after a while, we reach max client connection. To solve that, we must restart the webapp, which forces to restart postgresql as well. That wipe out every connection. When we see these idle forever, we are asking if we could set a timeout on each connection/session (I honestly don't know the correct terminology, sorry). If a transaction takes 5 minutes for a normal web app something must be wrong....

– user1012451
Nov 6 '12 at 5:26





@CraigRinger after a while, we reach max client connection. To solve that, we must restart the webapp, which forces to restart postgresql as well. That wipe out every connection. When we see these idle forever, we are asking if we could set a timeout on each connection/session (I honestly don't know the correct terminology, sorry). If a transaction takes 5 minutes for a normal web app something must be wrong....

– user1012451
Nov 6 '12 at 5:26












4 Answers
4






active

oldest

votes


















93














It sounds like you have a connection leak in your application because it fails to close pooled connections. You aren't having issues just with <idle> in transaction sessions, but with too many connections overall.



Killing connections is not the right answer for that, but it's an OK-ish temporary workaround.



Rather than re-starting PostgreSQL to boot all other connections off a PostgreSQL database, see: How do I detach all other users from a postgres database? and How to drop a PostgreSQL database if there are active connections to it? . The latter shows a better query.



For setting timeouts, as @Doon suggested see How to close idle connections in PostgreSQL automatically?, which advises you to use PgBouncer to proxy for PostgreSQL and manage idle connections. This is a very good idea if you have a buggy application that leaks connections anyway; I very strongly recommend configuring PgBouncer.



A TCP keepalive won't do the job here, because the app is still connected and alive, it just shouldn't be.



In PostgreSQL 9.2 and above, you can use the new state_change timestamp column and the state field of pg_stat_activity to implement an idle connection reaper. Have a cron job run something like this:



SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE datname = 'regress'
AND pid <> pg_backend_pid()
AND state = 'idle'
AND state_change < current_timestamp - INTERVAL '5' MINUTE;


In older versions you need to implement complicated schemes that keep track of when the connection went idle. Do not bother; just use pgbouncer.






share|improve this answer





















  • 2





    Good, but it will kill other PgAdmin backends. Use additional condition application_name=''

    – Andrew Selivanov
    Apr 19 '13 at 12:54











  • Can I run pg_terminate_backend if I'm using pgbouncer?

    – Henley Chiu
    Dec 11 '13 at 23:06











  • @HenleyChiu I don't see why not, though I haven't specifically checked.

    – Craig Ringer
    Dec 11 '13 at 23:12











  • Running this seems to have killed my WAL sender process

    – Joseph Persie
    Feb 9 '16 at 15:24











  • @CraigRinger even a psql connection is considered as idle connection. And why does one has to close the idle connection at first place. I have a long running code that establish connection with pg perform some dml operation and the then wait for the message over queue and then perform some more dml operation.Now during that period i.e while it is waiting over queue(for message) as mention above even then the connection with postges is idle. why should i close it.

    – Viren
    Apr 15 '16 at 18:13



















47














In PostgreSQL 9.6, there's a new option idle_in_transaction_session_timeout which should accomplish what you describe. You can set it using the SET command, e.g.:



SET SESSION idle_in_transaction_session_timeout = '5min';





share|improve this answer





















  • 1





    It sucks having to ask something so simple but I'm brand new to databases in general - Could you please give a very basic example of how to use this function?

    – s g
    Mar 31 '17 at 17:54






  • 4





    No problem, updated the answer.

    – shosti
    Mar 31 '17 at 21:39











  • Anything like this in previous versions of PostgreSQL??

    – sdsc81
    Sep 25 '17 at 20:06











  • No, something akin to the other answers is required for previous versions.

    – shosti
    Sep 25 '17 at 23:46











  • Do you need to set this parameter at every restart of database? Or after you did once you can forget about? Thanks

    – fresko
    Oct 8 '18 at 13:33



















17














In PostgreSQL 9.1, the idle connections with following query. It helped me to ward off the situation which warranted in restarting the database. This happens mostly with JDBC connections opened and not closed properly.



SELECT
pg_terminate_backend(procpid)
FROM
pg_stat_activity
WHERE
current_query = '<IDLE>'
AND
now() - query_start > '00:10:00';





share|improve this answer


























  • pg_terminate_backend is in since 8.4

    – Andrew Banks
    Apr 21 '15 at 17:36



















2














if you are using postgresql 9.6+, then in your postgresql.conf you can set



idle_in_transaction_session_timeout = 30000 (msec)






share|improve this answer

























    Your Answer






    StackExchange.ifUsing("editor", function () {
    StackExchange.using("externalEditor", function () {
    StackExchange.using("snippets", function () {
    StackExchange.snippets.init();
    });
    });
    }, "code-snippets");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "1"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f13236160%2fis-there-a-timeout-for-idle-postgresql-connections%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    4 Answers
    4






    active

    oldest

    votes








    4 Answers
    4






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    93














    It sounds like you have a connection leak in your application because it fails to close pooled connections. You aren't having issues just with <idle> in transaction sessions, but with too many connections overall.



    Killing connections is not the right answer for that, but it's an OK-ish temporary workaround.



    Rather than re-starting PostgreSQL to boot all other connections off a PostgreSQL database, see: How do I detach all other users from a postgres database? and How to drop a PostgreSQL database if there are active connections to it? . The latter shows a better query.



    For setting timeouts, as @Doon suggested see How to close idle connections in PostgreSQL automatically?, which advises you to use PgBouncer to proxy for PostgreSQL and manage idle connections. This is a very good idea if you have a buggy application that leaks connections anyway; I very strongly recommend configuring PgBouncer.



    A TCP keepalive won't do the job here, because the app is still connected and alive, it just shouldn't be.



    In PostgreSQL 9.2 and above, you can use the new state_change timestamp column and the state field of pg_stat_activity to implement an idle connection reaper. Have a cron job run something like this:



    SELECT pg_terminate_backend(pid)
    FROM pg_stat_activity
    WHERE datname = 'regress'
    AND pid <> pg_backend_pid()
    AND state = 'idle'
    AND state_change < current_timestamp - INTERVAL '5' MINUTE;


    In older versions you need to implement complicated schemes that keep track of when the connection went idle. Do not bother; just use pgbouncer.






    share|improve this answer





















    • 2





      Good, but it will kill other PgAdmin backends. Use additional condition application_name=''

      – Andrew Selivanov
      Apr 19 '13 at 12:54











    • Can I run pg_terminate_backend if I'm using pgbouncer?

      – Henley Chiu
      Dec 11 '13 at 23:06











    • @HenleyChiu I don't see why not, though I haven't specifically checked.

      – Craig Ringer
      Dec 11 '13 at 23:12











    • Running this seems to have killed my WAL sender process

      – Joseph Persie
      Feb 9 '16 at 15:24











    • @CraigRinger even a psql connection is considered as idle connection. And why does one has to close the idle connection at first place. I have a long running code that establish connection with pg perform some dml operation and the then wait for the message over queue and then perform some more dml operation.Now during that period i.e while it is waiting over queue(for message) as mention above even then the connection with postges is idle. why should i close it.

      – Viren
      Apr 15 '16 at 18:13
















    93














    It sounds like you have a connection leak in your application because it fails to close pooled connections. You aren't having issues just with <idle> in transaction sessions, but with too many connections overall.



    Killing connections is not the right answer for that, but it's an OK-ish temporary workaround.



    Rather than re-starting PostgreSQL to boot all other connections off a PostgreSQL database, see: How do I detach all other users from a postgres database? and How to drop a PostgreSQL database if there are active connections to it? . The latter shows a better query.



    For setting timeouts, as @Doon suggested see How to close idle connections in PostgreSQL automatically?, which advises you to use PgBouncer to proxy for PostgreSQL and manage idle connections. This is a very good idea if you have a buggy application that leaks connections anyway; I very strongly recommend configuring PgBouncer.



    A TCP keepalive won't do the job here, because the app is still connected and alive, it just shouldn't be.



    In PostgreSQL 9.2 and above, you can use the new state_change timestamp column and the state field of pg_stat_activity to implement an idle connection reaper. Have a cron job run something like this:



    SELECT pg_terminate_backend(pid)
    FROM pg_stat_activity
    WHERE datname = 'regress'
    AND pid <> pg_backend_pid()
    AND state = 'idle'
    AND state_change < current_timestamp - INTERVAL '5' MINUTE;


    In older versions you need to implement complicated schemes that keep track of when the connection went idle. Do not bother; just use pgbouncer.






    share|improve this answer





















    • 2





      Good, but it will kill other PgAdmin backends. Use additional condition application_name=''

      – Andrew Selivanov
      Apr 19 '13 at 12:54











    • Can I run pg_terminate_backend if I'm using pgbouncer?

      – Henley Chiu
      Dec 11 '13 at 23:06











    • @HenleyChiu I don't see why not, though I haven't specifically checked.

      – Craig Ringer
      Dec 11 '13 at 23:12











    • Running this seems to have killed my WAL sender process

      – Joseph Persie
      Feb 9 '16 at 15:24











    • @CraigRinger even a psql connection is considered as idle connection. And why does one has to close the idle connection at first place. I have a long running code that establish connection with pg perform some dml operation and the then wait for the message over queue and then perform some more dml operation.Now during that period i.e while it is waiting over queue(for message) as mention above even then the connection with postges is idle. why should i close it.

      – Viren
      Apr 15 '16 at 18:13














    93












    93








    93







    It sounds like you have a connection leak in your application because it fails to close pooled connections. You aren't having issues just with <idle> in transaction sessions, but with too many connections overall.



    Killing connections is not the right answer for that, but it's an OK-ish temporary workaround.



    Rather than re-starting PostgreSQL to boot all other connections off a PostgreSQL database, see: How do I detach all other users from a postgres database? and How to drop a PostgreSQL database if there are active connections to it? . The latter shows a better query.



    For setting timeouts, as @Doon suggested see How to close idle connections in PostgreSQL automatically?, which advises you to use PgBouncer to proxy for PostgreSQL and manage idle connections. This is a very good idea if you have a buggy application that leaks connections anyway; I very strongly recommend configuring PgBouncer.



    A TCP keepalive won't do the job here, because the app is still connected and alive, it just shouldn't be.



    In PostgreSQL 9.2 and above, you can use the new state_change timestamp column and the state field of pg_stat_activity to implement an idle connection reaper. Have a cron job run something like this:



    SELECT pg_terminate_backend(pid)
    FROM pg_stat_activity
    WHERE datname = 'regress'
    AND pid <> pg_backend_pid()
    AND state = 'idle'
    AND state_change < current_timestamp - INTERVAL '5' MINUTE;


    In older versions you need to implement complicated schemes that keep track of when the connection went idle. Do not bother; just use pgbouncer.






    share|improve this answer















    It sounds like you have a connection leak in your application because it fails to close pooled connections. You aren't having issues just with <idle> in transaction sessions, but with too many connections overall.



    Killing connections is not the right answer for that, but it's an OK-ish temporary workaround.



    Rather than re-starting PostgreSQL to boot all other connections off a PostgreSQL database, see: How do I detach all other users from a postgres database? and How to drop a PostgreSQL database if there are active connections to it? . The latter shows a better query.



    For setting timeouts, as @Doon suggested see How to close idle connections in PostgreSQL automatically?, which advises you to use PgBouncer to proxy for PostgreSQL and manage idle connections. This is a very good idea if you have a buggy application that leaks connections anyway; I very strongly recommend configuring PgBouncer.



    A TCP keepalive won't do the job here, because the app is still connected and alive, it just shouldn't be.



    In PostgreSQL 9.2 and above, you can use the new state_change timestamp column and the state field of pg_stat_activity to implement an idle connection reaper. Have a cron job run something like this:



    SELECT pg_terminate_backend(pid)
    FROM pg_stat_activity
    WHERE datname = 'regress'
    AND pid <> pg_backend_pid()
    AND state = 'idle'
    AND state_change < current_timestamp - INTERVAL '5' MINUTE;


    In older versions you need to implement complicated schemes that keep track of when the connection went idle. Do not bother; just use pgbouncer.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Jan 20 at 17:31









    Hugo Leao

    50157




    50157










    answered Nov 6 '12 at 5:37









    Craig RingerCraig Ringer

    197k35401528




    197k35401528








    • 2





      Good, but it will kill other PgAdmin backends. Use additional condition application_name=''

      – Andrew Selivanov
      Apr 19 '13 at 12:54











    • Can I run pg_terminate_backend if I'm using pgbouncer?

      – Henley Chiu
      Dec 11 '13 at 23:06











    • @HenleyChiu I don't see why not, though I haven't specifically checked.

      – Craig Ringer
      Dec 11 '13 at 23:12











    • Running this seems to have killed my WAL sender process

      – Joseph Persie
      Feb 9 '16 at 15:24











    • @CraigRinger even a psql connection is considered as idle connection. And why does one has to close the idle connection at first place. I have a long running code that establish connection with pg perform some dml operation and the then wait for the message over queue and then perform some more dml operation.Now during that period i.e while it is waiting over queue(for message) as mention above even then the connection with postges is idle. why should i close it.

      – Viren
      Apr 15 '16 at 18:13














    • 2





      Good, but it will kill other PgAdmin backends. Use additional condition application_name=''

      – Andrew Selivanov
      Apr 19 '13 at 12:54











    • Can I run pg_terminate_backend if I'm using pgbouncer?

      – Henley Chiu
      Dec 11 '13 at 23:06











    • @HenleyChiu I don't see why not, though I haven't specifically checked.

      – Craig Ringer
      Dec 11 '13 at 23:12











    • Running this seems to have killed my WAL sender process

      – Joseph Persie
      Feb 9 '16 at 15:24











    • @CraigRinger even a psql connection is considered as idle connection. And why does one has to close the idle connection at first place. I have a long running code that establish connection with pg perform some dml operation and the then wait for the message over queue and then perform some more dml operation.Now during that period i.e while it is waiting over queue(for message) as mention above even then the connection with postges is idle. why should i close it.

      – Viren
      Apr 15 '16 at 18:13








    2




    2





    Good, but it will kill other PgAdmin backends. Use additional condition application_name=''

    – Andrew Selivanov
    Apr 19 '13 at 12:54





    Good, but it will kill other PgAdmin backends. Use additional condition application_name=''

    – Andrew Selivanov
    Apr 19 '13 at 12:54













    Can I run pg_terminate_backend if I'm using pgbouncer?

    – Henley Chiu
    Dec 11 '13 at 23:06





    Can I run pg_terminate_backend if I'm using pgbouncer?

    – Henley Chiu
    Dec 11 '13 at 23:06













    @HenleyChiu I don't see why not, though I haven't specifically checked.

    – Craig Ringer
    Dec 11 '13 at 23:12





    @HenleyChiu I don't see why not, though I haven't specifically checked.

    – Craig Ringer
    Dec 11 '13 at 23:12













    Running this seems to have killed my WAL sender process

    – Joseph Persie
    Feb 9 '16 at 15:24





    Running this seems to have killed my WAL sender process

    – Joseph Persie
    Feb 9 '16 at 15:24













    @CraigRinger even a psql connection is considered as idle connection. And why does one has to close the idle connection at first place. I have a long running code that establish connection with pg perform some dml operation and the then wait for the message over queue and then perform some more dml operation.Now during that period i.e while it is waiting over queue(for message) as mention above even then the connection with postges is idle. why should i close it.

    – Viren
    Apr 15 '16 at 18:13





    @CraigRinger even a psql connection is considered as idle connection. And why does one has to close the idle connection at first place. I have a long running code that establish connection with pg perform some dml operation and the then wait for the message over queue and then perform some more dml operation.Now during that period i.e while it is waiting over queue(for message) as mention above even then the connection with postges is idle. why should i close it.

    – Viren
    Apr 15 '16 at 18:13













    47














    In PostgreSQL 9.6, there's a new option idle_in_transaction_session_timeout which should accomplish what you describe. You can set it using the SET command, e.g.:



    SET SESSION idle_in_transaction_session_timeout = '5min';





    share|improve this answer





















    • 1





      It sucks having to ask something so simple but I'm brand new to databases in general - Could you please give a very basic example of how to use this function?

      – s g
      Mar 31 '17 at 17:54






    • 4





      No problem, updated the answer.

      – shosti
      Mar 31 '17 at 21:39











    • Anything like this in previous versions of PostgreSQL??

      – sdsc81
      Sep 25 '17 at 20:06











    • No, something akin to the other answers is required for previous versions.

      – shosti
      Sep 25 '17 at 23:46











    • Do you need to set this parameter at every restart of database? Or after you did once you can forget about? Thanks

      – fresko
      Oct 8 '18 at 13:33
















    47














    In PostgreSQL 9.6, there's a new option idle_in_transaction_session_timeout which should accomplish what you describe. You can set it using the SET command, e.g.:



    SET SESSION idle_in_transaction_session_timeout = '5min';





    share|improve this answer





















    • 1





      It sucks having to ask something so simple but I'm brand new to databases in general - Could you please give a very basic example of how to use this function?

      – s g
      Mar 31 '17 at 17:54






    • 4





      No problem, updated the answer.

      – shosti
      Mar 31 '17 at 21:39











    • Anything like this in previous versions of PostgreSQL??

      – sdsc81
      Sep 25 '17 at 20:06











    • No, something akin to the other answers is required for previous versions.

      – shosti
      Sep 25 '17 at 23:46











    • Do you need to set this parameter at every restart of database? Or after you did once you can forget about? Thanks

      – fresko
      Oct 8 '18 at 13:33














    47












    47








    47







    In PostgreSQL 9.6, there's a new option idle_in_transaction_session_timeout which should accomplish what you describe. You can set it using the SET command, e.g.:



    SET SESSION idle_in_transaction_session_timeout = '5min';





    share|improve this answer















    In PostgreSQL 9.6, there's a new option idle_in_transaction_session_timeout which should accomplish what you describe. You can set it using the SET command, e.g.:



    SET SESSION idle_in_transaction_session_timeout = '5min';






    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Mar 31 '17 at 21:38

























    answered Jan 24 '17 at 1:09









    shostishosti

    6,21233241




    6,21233241








    • 1





      It sucks having to ask something so simple but I'm brand new to databases in general - Could you please give a very basic example of how to use this function?

      – s g
      Mar 31 '17 at 17:54






    • 4





      No problem, updated the answer.

      – shosti
      Mar 31 '17 at 21:39











    • Anything like this in previous versions of PostgreSQL??

      – sdsc81
      Sep 25 '17 at 20:06











    • No, something akin to the other answers is required for previous versions.

      – shosti
      Sep 25 '17 at 23:46











    • Do you need to set this parameter at every restart of database? Or after you did once you can forget about? Thanks

      – fresko
      Oct 8 '18 at 13:33














    • 1





      It sucks having to ask something so simple but I'm brand new to databases in general - Could you please give a very basic example of how to use this function?

      – s g
      Mar 31 '17 at 17:54






    • 4





      No problem, updated the answer.

      – shosti
      Mar 31 '17 at 21:39











    • Anything like this in previous versions of PostgreSQL??

      – sdsc81
      Sep 25 '17 at 20:06











    • No, something akin to the other answers is required for previous versions.

      – shosti
      Sep 25 '17 at 23:46











    • Do you need to set this parameter at every restart of database? Or after you did once you can forget about? Thanks

      – fresko
      Oct 8 '18 at 13:33








    1




    1





    It sucks having to ask something so simple but I'm brand new to databases in general - Could you please give a very basic example of how to use this function?

    – s g
    Mar 31 '17 at 17:54





    It sucks having to ask something so simple but I'm brand new to databases in general - Could you please give a very basic example of how to use this function?

    – s g
    Mar 31 '17 at 17:54




    4




    4





    No problem, updated the answer.

    – shosti
    Mar 31 '17 at 21:39





    No problem, updated the answer.

    – shosti
    Mar 31 '17 at 21:39













    Anything like this in previous versions of PostgreSQL??

    – sdsc81
    Sep 25 '17 at 20:06





    Anything like this in previous versions of PostgreSQL??

    – sdsc81
    Sep 25 '17 at 20:06













    No, something akin to the other answers is required for previous versions.

    – shosti
    Sep 25 '17 at 23:46





    No, something akin to the other answers is required for previous versions.

    – shosti
    Sep 25 '17 at 23:46













    Do you need to set this parameter at every restart of database? Or after you did once you can forget about? Thanks

    – fresko
    Oct 8 '18 at 13:33





    Do you need to set this parameter at every restart of database? Or after you did once you can forget about? Thanks

    – fresko
    Oct 8 '18 at 13:33











    17














    In PostgreSQL 9.1, the idle connections with following query. It helped me to ward off the situation which warranted in restarting the database. This happens mostly with JDBC connections opened and not closed properly.



    SELECT
    pg_terminate_backend(procpid)
    FROM
    pg_stat_activity
    WHERE
    current_query = '<IDLE>'
    AND
    now() - query_start > '00:10:00';





    share|improve this answer


























    • pg_terminate_backend is in since 8.4

      – Andrew Banks
      Apr 21 '15 at 17:36
















    17














    In PostgreSQL 9.1, the idle connections with following query. It helped me to ward off the situation which warranted in restarting the database. This happens mostly with JDBC connections opened and not closed properly.



    SELECT
    pg_terminate_backend(procpid)
    FROM
    pg_stat_activity
    WHERE
    current_query = '<IDLE>'
    AND
    now() - query_start > '00:10:00';





    share|improve this answer


























    • pg_terminate_backend is in since 8.4

      – Andrew Banks
      Apr 21 '15 at 17:36














    17












    17








    17







    In PostgreSQL 9.1, the idle connections with following query. It helped me to ward off the situation which warranted in restarting the database. This happens mostly with JDBC connections opened and not closed properly.



    SELECT
    pg_terminate_backend(procpid)
    FROM
    pg_stat_activity
    WHERE
    current_query = '<IDLE>'
    AND
    now() - query_start > '00:10:00';





    share|improve this answer















    In PostgreSQL 9.1, the idle connections with following query. It helped me to ward off the situation which warranted in restarting the database. This happens mostly with JDBC connections opened and not closed properly.



    SELECT
    pg_terminate_backend(procpid)
    FROM
    pg_stat_activity
    WHERE
    current_query = '<IDLE>'
    AND
    now() - query_start > '00:10:00';






    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Dec 30 '13 at 1:04









    Lucas Wilson-Richter

    1,8511421




    1,8511421










    answered May 16 '13 at 8:22









    sramaysramay

    18113




    18113













    • pg_terminate_backend is in since 8.4

      – Andrew Banks
      Apr 21 '15 at 17:36



















    • pg_terminate_backend is in since 8.4

      – Andrew Banks
      Apr 21 '15 at 17:36

















    pg_terminate_backend is in since 8.4

    – Andrew Banks
    Apr 21 '15 at 17:36





    pg_terminate_backend is in since 8.4

    – Andrew Banks
    Apr 21 '15 at 17:36











    2














    if you are using postgresql 9.6+, then in your postgresql.conf you can set



    idle_in_transaction_session_timeout = 30000 (msec)






    share|improve this answer






























      2














      if you are using postgresql 9.6+, then in your postgresql.conf you can set



      idle_in_transaction_session_timeout = 30000 (msec)






      share|improve this answer




























        2












        2








        2







        if you are using postgresql 9.6+, then in your postgresql.conf you can set



        idle_in_transaction_session_timeout = 30000 (msec)






        share|improve this answer















        if you are using postgresql 9.6+, then in your postgresql.conf you can set



        idle_in_transaction_session_timeout = 30000 (msec)







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Mar 4 '18 at 1:21









        e_i_pi

        2,68921832




        2,68921832










        answered Mar 3 '18 at 20:58









        Bertrand DavidBertrand David

        313




        313






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Stack Overflow!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f13236160%2fis-there-a-timeout-for-idle-postgresql-connections%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            鏡平學校

            ꓛꓣだゔៀៅຸ໢ທຮ໕໒ ,ໂ'໥໓າ໼ឨឲ៵៭ៈゎゔit''䖳𥁄卿' ☨₤₨こゎもょの;ꜹꟚꞖꞵꟅꞛေၦေɯ,ɨɡ𛃵𛁹ޝ޳ޠ޾,ޤޒޯ޾𫝒𫠁သ𛅤チョ'サノބޘދ𛁐ᶿᶇᶀᶋᶠ㨑㽹⻮ꧬ꧹؍۩وَؠ㇕㇃㇪ ㇦㇋㇋ṜẰᵡᴠ 軌ᵕ搜۳ٰޗޮ޷ސޯ𫖾𫅀ल, ꙭ꙰ꚅꙁꚊꞻꝔ꟠Ꝭㄤﺟޱސꧨꧼ꧴ꧯꧽ꧲ꧯ'⽹⽭⾁⿞⼳⽋២៩ញណើꩯꩤ꩸ꩮᶻᶺᶧᶂ𫳲𫪭𬸄𫵰𬖩𬫣𬊉ၲ𛅬㕦䬺𫝌𫝼,,𫟖𫞽ហៅ஫㆔ాఆఅꙒꚞꙍ,Ꙟ꙱エ ,ポテ,フࢰࢯ𫟠𫞶 𫝤𫟠ﺕﹱﻜﻣ𪵕𪭸𪻆𪾩𫔷ġ,ŧآꞪ꟥,ꞔꝻ♚☹⛵𛀌ꬷꭞȄƁƪƬșƦǙǗdžƝǯǧⱦⱰꓕꓢႋ神 ဴ၀க௭எ௫ឫោ ' េㇷㇴㇼ神ㇸㇲㇽㇴㇼㇻㇸ'ㇸㇿㇸㇹㇰㆣꓚꓤ₡₧ ㄨㄟ㄂ㄖㄎ໗ツڒذ₶।ऩछएोञयूटक़कयँृी,冬'𛅢𛅥ㇱㇵㇶ𥄥𦒽𠣧𠊓𧢖𥞘𩔋цѰㄠſtʯʭɿʆʗʍʩɷɛ,əʏダヵㄐㄘR{gỚṖḺờṠṫảḙḭᴮᵏᴘᵀᵷᵕᴜᴏᵾq﮲ﲿﴽﭙ軌ﰬﶚﶧ﫲Ҝжюїкӈㇴffצּ﬘﭅﬈軌'ffistfflſtffतभफɳɰʊɲʎ𛁱𛁖𛁮𛀉 𛂯𛀞నఋŀŲ 𫟲𫠖𫞺ຆຆ ໹້໕໗ๆทԊꧢꧠ꧰ꓱ⿝⼑ŎḬẃẖỐẅ ,ờỰỈỗﮊDžȩꭏꭎꬻ꭮ꬿꭖꭥꭅ㇭神 ⾈ꓵꓑ⺄㄄ㄪㄙㄅㄇstA۵䞽ॶ𫞑𫝄㇉㇇゜軌𩜛𩳠Jﻺ‚Üမ႕ႌႊၐၸဓၞၞၡ៸wyvtᶎᶪᶹစဎ꣡꣰꣢꣤ٗ؋لㇳㇾㇻㇱ㆐㆔,,㆟Ⱶヤマފ޼ޝަݿݞݠݷݐ',ݘ,ݪݙݵ𬝉𬜁𫝨𫞘くせぉて¼óû×ó£…𛅑הㄙくԗԀ5606神45,神796'𪤻𫞧ꓐ㄁ㄘɥɺꓵꓲ3''7034׉ⱦⱠˆ“𫝋ȍ,ꩲ軌꩷ꩶꩧꩫఞ۔فڱێظペサ神ナᴦᵑ47 9238їﻂ䐊䔉㠸﬎ffiﬣ,לּᴷᴦᵛᵽ,ᴨᵤ ᵸᵥᴗᵈꚏꚉꚟ⻆rtǟƴ𬎎

            Why https connections are so slow when debugging (stepping over) in Java?