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
