Re: Built-in connection pooler

On 29.01.2019 8:14, Michael Paquier wrote:
> On Mon, Jan 28, 2019 at 10:33:06PM +0100, Dimitri Fontaine wrote:
>> In other cases, it's important to measure and accept the possible
>> performance cost of running a proxy server between the client connection
>> and the PostgreSQL backend process. I believe the numbers shown in the
>> previous email by Konstantin are about showing the kind of impact you
>> can see when using the patch in a use-case where it's not meant to be
>> helping much, if at all.
> Have you looked at the possibility of having the proxy worker be
> spawned as a background worker?

Yes, it was my first attempt.
The main reason why I have implemented it in old ways are:
1. I need to know PID of spawned worker. Strange - it is possible to get
PID of dynamic bgworker, but no of static one.
Certainly it is possible  to find a way of passing this PID to
postmaster but it complicates start of worker.
2. I need to pass socket to spawner proxy.  Once again: it can be
implemented also with bgworker but requires more coding (especially
taken in account support of Win32 and FORKEXEC mode).

> I think that we should avoid spawning
> any new processes on the backend from the ground as we have a lot more
> infrastructures since 9.3. The patch should actually be bigger, the
> code is very raw and lacks comments in a lot of areas where the logic
> is not so obvious, except perhaps to the patch author.

The main reason for publishing this patch was to receive feedbacks and
find places which should be rewritten.
I will add more comments but I will be pleased if you point me which
places are obscure now and require better explanation.

--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company