[pgpool-general: 4142] Re: Stuck connections in 4.3.4 RPM

[Piotr Dydycz]

Thanks.

I took a look at the patch
http://git.postgresql.org/gitweb/?p=pgpool2.git;a=commit;h=04a288318951869587f74e808b243115dfcb2652
again and for my understanding it seems that issue will not be preset
if I set connection_cache = false in pgpool.conf.

In backend_cleanup routine If pool_config->connection_cache returns 0
local variable bool cache_connection will be false then this code

if (cache_connection == false)
    {
                pool_send_frontend_exits(backend);
        if(sp)
            pool_discard_cp(sp->user, sp->database, sp->major);
    }

will be executed and I believe this is what this patch essentially
does (force not to  cache connection).

If fact I'm not using connection cache as I have:
num_init_children = 250
max_pool = 1

Could you please validate my reasoning above?

Regards,
PD







On 24 October 2015 at 03:37, Tatsuo Ishii <ishii at postgresql.org> wrote:
>> Hi,
>>
>> It seems like RPM for 3.4.3 which is (in my case)
>> http://www.pgpool.net/yum/rpms/3.4/redhat/rhel-6-x86_64/pgpool-II-pg93-3.4.3-1pgdg.rhel6.x86_64.rpm
>> doesn't have this
>> http://git.postgresql.org/gitweb/?p=pgpool2.git;a=commit;h=04a288318951869587f74e808b243115dfcb2652
>> patch applied.
>>
>> I'm using this version on production and it exhibits behaviour same as
>> described here:
>> http://www.pgpool.net/mantisbt/view.php?id=107
>>
>> Am I right that this problem is not patched in 3.4.3 RPM version?
>
> You are correct.
>
>> Are you going to publish new RPM with this problem fixed soon?
>
> Probably with the same timing when the next minor versions are out,
> which we plan in mid December.
>
>> What approach could you recommend? Downgrade to 3.3?
>> Is there any workaround that could help to cope with this issue?
>
> Maybe download the SRPM and apply the patch and rebuild the RPM?
>
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp