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

From Ryan Lambert
Subject Re: Built-in connection pooler
Date
Msg-id CAN-V+g8h5HFQj_Y7HzFvcuCzOL=F8VDadNxCwQ8exkKOYB8KJA@mail.gmail.com
Whole thread Raw
In response to Re: Built-in connection pooler  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Responses Re: Built-in connection pooler  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
List pgsql-hackers
Hi Konstantin,

Thanks for your work on this.  I'll try to do more testing in the next few days, here's what I have so far.

make installcheck-world: passed

The v8 patch [1] applies, though I get indent and whitespace errors:

<stdin>:79: tab in indent.
                 "Each proxy launches its own subset of backends. So maximal number of non-tainted backends is "
<stdin>:80: tab in indent.
                  "session_pool_size*connection_proxies*databases*roles.
<stdin>:519: indent with spaces.
    char buf[CMSG_SPACE(sizeof(sock))];
<stdin>:520: indent with spaces.
    memset(buf, '\0', sizeof(buf));
<stdin>:522: indent with spaces.
    /* On Mac OS X, the struct iovec is needed, even if it points to minimal data */
warning: squelched 82 whitespace errors
warning: 87 lines add whitespace errors.


In connpool.sgml:

"but it can be changed to standard Postgres 4321"

Should be 5432?

" As far as pooled backends are not terminated on client exist, it will not
    be possible to drop database to which them are connected."

Active discussion in [2] might change that, it is also in this July commitfest [3].

"Unlike pgbouncer and other external connection poolera"

Should be "poolers"

"So developers of client applications still have a choice
    either to avoid using session-specific operations either not to use pooling."

That sentence isn't smooth for me to read.  Maybe something like:
"Developers of client applications have the choice to either avoid using session-specific operations, or not use built-in pooling."

On Tue, Jul 16, 2019 at 12:20 AM Konstantin Knizhnik <k.knizhnik@postgrespro.ru> wrote:


On 15.07.2019 17:04, Konstantin Knizhnik wrote:
>
>
> On 14.07.2019 8:03, Thomas Munro wrote:
>>
>> On my FreeBSD box (which doesn't have epoll(), so it's latch.c's old
>> school poll() for now), I see the connection proxy process eating a
>> lot of CPU and the temperature rising.  I see with truss that it's
>> doing this as fast as it can:
>>
>> poll({ 13/POLLIN 17/POLLIN|POLLOUT },2,1000)     = 1 (0x1)
>>
>> Ouch.  I admit that I had the idea to test on FreeBSD because I
>> noticed the patch introduces EPOLLET and I figured this might have
>> been tested only on Linux.  FWIW the same happens on a Mac.
>>
> I have committed patch which emulates epoll EPOLLET flag and so should
> avoid busy loop with poll().
> I will be pleased if you can check it at FreeBSD  box.
>
>
Sorry, attached patch was incomplete.
Please try this version of the patch.

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Speed up transaction completion faster after many relations areaccessed in a transaction
Next
From: Masahiko Sawada
Date:
Subject: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)