| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Isaac Morland <isaac(dot)morland(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: zombie connections |
| Date: | 2020-04-03 16:32:01 |
| Message-ID: | CA+TgmoZozbTfGWW1JbfSvbV1BBnjCHatcavKuzdZ83t61nD_VQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Apr 3, 2020 at 11:50 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> (2) It only wins if a statement timeout is active, otherwise it makes
> things worse, because then you need setitimer() at statement start
> and end just to enable/disable the socket check timeout. Whereas
> if you just let a once-a-minute timeout continue to run, you don't
> incur those kernel calls.
Oh, that's a really good point. I should have thought of that.
> Anyway, the core problem with the originally-submitted patch was that
> it was totally ignorant that timeout.c had restrictions it was breaking.
> You can either fix the restrictions, or you can try to design around them,
> but you've got to be aware of what that code can and can't do today.
No disagreement there.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2020-04-03 16:45:13 | Re: Add A Glossary |
| Previous Message | Jehan-Guillaume de Rorthais | 2020-04-03 16:26:25 | Re: [BUG] non archived WAL removed during production crash recovery |