| From: | Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Claudio Freire <klaussfreire(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Built-in connection pooling |
| Date: | 2018-01-29 19:06:25 |
| Message-ID: | CAB=Je-FTdk_XsBn9FnG1=qMopeKXA+5cqq27-4oeRxAZht_+BQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Bruce>Well, we could have the connection pooler disconnect those, right?
I agree. Do you think we could rely on all the applications being
configured in a sane way?
A fallback configuration at DB level could still be useful to ensure the DB
keeps running in case multiple applications access it. It might be
non-trivial to ensure proper configurations across all the apps.
What I do like is the behaviour of dropping connections should already be
considered by existing applications, so it should fit naturally to the
existing apps.
Alternative approach might be to dump to disk relevant resources for
inactive sessions, so the session could be recreated in case the connection
is requested again after a long pause (e.g. reprepare all the statements),
however it sounds scary.
Vladimir
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2018-01-29 20:30:12 | Re: FOR EACH ROW triggers on partitioned tables |
| Previous Message | Andres Freund | 2018-01-29 18:40:06 | Re: JIT compiling with LLVM v9.0 |