RE: Built-in connection pooler - Mailing list pgsql-hackers

From ideriha.takeshi@fujitsu.com
Subject RE: Built-in connection pooler
Date
Msg-id OSAPR01MB1985068ABB08A85828999460EA770@OSAPR01MB1985.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Built-in connection pooler  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Responses Re: Built-in connection pooler
List pgsql-hackers
Hi.

>From: Konstantin Knizhnik [mailto:k.knizhnik@postgrespro.ru]
>
>New version of builtin connection pooler fixing handling messages of extended
>protocol.
>
Here are things I've noticed.

1. Is adding guc to postgresql.conf.sample useful for users?

2. When proxy_port is a bit large (perhaps more than 2^15), connection failed
though regular "port" is fine with number more than 2^15.

$ bin/psql -p  32768
2019-11-12 16:11:25.460 JST [5617] LOG:  Message size 84
2019-11-12 16:11:25.461 JST [5617] WARNING:  could not setup local connect to server
2019-11-12 16:11:25.461 JST [5617] DETAIL:  invalid port number: "-22768"
2019-11-12 16:11:25.461 JST [5617] LOG:  Handshake response will be sent to the client later when backed is assigned
psql: error: could not connect to server: invalid port number: "-22768"

3. When porxy_port is 6543 and connection_proxies is 2, running "make installcheck" twice without restarting server
failed.
This is because of remaining backend.

============== dropping database "regression"         ==============
ERROR:  database "regression" is being accessed by other users
DETAIL:  There is 1 other session using the database.
command failed: "/usr/local/pgsql-connection-proxy-performance/bin/psql" -X -c "DROP DATABASE IF EXISTS \"regression\""
"postgres"

4. When running "make installcheck-world" with various connection-proxies, it results in a different number of errors.
With connection_proxies = 2, the test never ends. With connection_proxies = 20, 23 tests failed.
More connection_proxies, the number of failed tests decreased.

Regards,
Takeshi Ideriha

pgsql-hackers by date:

Previous
From: Yonatan Misgan
Date:
Subject: Extension development
Next
From: Konstantin Knizhnik
Date:
Subject: Re: Why overhead of SPI is so large?