From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Voinea <rvoinea(at)gmail(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #5465: dblink TCP connection hangs blocking translation from being terminated |
Date: | 2014-03-14 13:45:22 |
Message-ID: | 3110.1394804722@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Robert Voinea <rvoinea(at)gmail(dot)com> writes:
> In our setup, we make use extensively of dblink.
> Due to the fact that some queries take some time to complete and that the link
> is over the internet, sometime the server process (the transaction that runs
> the dblink queries) hangs when the link goes down, keeping locks on several
> records plus some advisory locks and thus freezing the whole (most of) the
> database.
> What I have found is this bug, that is remarkably similar (if not identical)
> with what we are experiencing.
> http://postgresql.1045698.n5.nabble.com/BUG-5465-dblink-TCP-connection-hangs-blocking-translation-from-being-terminated-td2132419.html#a2132420
That does not sound like a Postgres bug to me. What you are unhappy about
is that the kernel isn't timing out a lost TCP connection more quickly.
The default timeout is long (>1 hour probably), but that's required by
Internet standards. The appropriate fix for this is to use aggressive
keepalive parameters on the connection. You can set libpq's keepalive
parameters in the connection string given to dblink.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2014-03-14 14:05:43 | Re: need information licenses costs. |
Previous Message | 上原 一樹 | 2014-03-14 09:30:58 | Re: BUG #9541: Result of TRIM function has changed |