[pgpool-general: 8215] Re: Pgpool reporting inconsistent statuses

Felix Rubio felix at kngnt.org
Wed Jun 15 18:01:17 JST 2022


Going through the mailing list archives, I have made another check: 
Should I run "select pg_is_in_recovery()" in each of the nodes, I get 
'f' on the primary, and 't' on the secondaries... so seems that is also 
ok on that front.

---
Felix Rubio
"Don't believe what you're told. Double check."

On 2022-06-14 13:50, Felix Rubio wrote:
> Hi everybody,
> 
> I have managed to set up, from scratch, a postgresql 14 + pgpool 4.3.2
> cluster, with streaming replication. I have also a simple test that
> creates a database, a table on it, and adds some records, to then
> check on all the members of the cluster if replication has been
> successful.
> 
> If I point my test to the primary node of the streaming replication
> cluster, my test succeeds and all is OK.
> 
> When I set up everything through pgpool, all seems to work:
> 
>  node_id |  hostname  | port | status | pg_status | lb_weight |  role
>  | pg_role | select_cnt | load_balance_node | replication_delay |
> replication_state | replication_sync_state | last_status_change
> ---------+------------+------+--------+-----------+-----------+---------+---------+------------+-------------------+-------------------+-------------------+------------------------+---------------------
>  0       | pgsql-0000 | 5433 | up     | up        | 0.333333  |
> primary | primary | 0          | false             | 0
> |                   |                        | 2022-06-14 11:28:11
>  1       | pgsql-0001 | 5433 | up     | up        | 0.333333  |
> standby | standby | 0          | false             | 0
> | streaming         | async                  | 2022-06-14 11:28:11
>  2       | pgsql-0002 | 5433 | up     | up        | 0.333333  |
> standby | standby | 0          | true              | 0
> | streaming         | async                  | 2022-06-14 11:28:11
> 
> 
> If now run my test, this is what I get back:
> "DETAIL:  kind does not match between main(53) slot[1] (45)"
> 
> I have found an article claiming this is a problem caused by the
> number of connections. To this end, I have max_connections=40 in
> postgresql, and num_init_children=7 and max_pool=5 in pgpool.conf. As
> 5*7 < 40, I should ok on the side. Does anybody has a clue on what
> might be going on, here?
> 
> Regards!


More information about the pgpool-general mailing list