[Pgpool-general] Current problems in pgpool2.1b2+segfault patch

[Simone Tregnago]

Nico -telmich- Schottelius wrote:
> Hello!
> 
> Currently I had to disable pgpool, because of the following problems:
> 
> - no real logging support

uhm? what to you mean as 'real logging'? The log you've reported below 
isn't enough?

> 
> - too often disconnects: 
> 
> 2008-05-30 09:45:19 LOG:   pid 15208: statement: begin; select data from php_sessions where session_id = 'cd4752abe
> 216370eeec09e8dde9354f7' for update; 
> 2008-05-30 09:45:19 LOG:   pid 15252: statement: begin; select data from php_sessions where session_id = '87df8fc96
> 924eba9999f2aceb3dfbd5b' for update; 
> 2008-05-30 09:45:19 LOG:   pid 14567: statement:  RESET ALL
> 2008-05-30 09:45:19 LOG:   pid 14567: statement:  SET SESSION AUTHORIZATION DEFAULT
> 2008-05-30 09:45:19 ERROR: pid 15252: pool_process_query: 1 th kind C does not match with master connection kind D
> 2008-05-30 09:45:19 LOG:   pid 15252: notice_backend_error: 1 fail over request from pid 15252
> 2008-05-30 09:45:19 LOG:   pid 5045: starting degeneration. shutdown host 62.65.130.180(6543)
> 
> There are just too many situations, when a node is disconnected

disconnects rightly occurs when there is data mismatch between backends.
If you have a lot of data mismatch disconnects, probably you've big 
troubles with your databases. Full resync them and try again, if it 
always happens then there's something wrong (for ex. another app connect 
directly with one db and change data)

Reading your log seems that you're using "select ... for update" 
statements.
Well, from pgpool doc:

'''
condition for load balance

For the query to be load balanced, all the requirements below must be met:
...
     * it's not SELECT FOR UPDATE
...
'''

So, pay attention to not use load balancing if you need select for 
update clauses.

> - problems on syncing, even with PITR: As the applications do not release the connection
>   from pgpool, the pgp_recovery_node only works if I restart pgpool and insert
>   an iptables -j REJECT to the right port before the whole sync
>    -> more downtime than just for PITR

sorry, I haven't used PITR

> - connection problems when one backend is down / the available connections
>   at the backends are full: no answer from pgpool

Sure, if you've filled the number of connections you can't connect 
anymore. It's a config problem.

> - no / wrong reuse of existing connections: pgpool opens up to the maximum number
>   of connections persistent to the backends, but does NOT reuse them until all
>   are opened (afaics) -> leads to strange behaviour if the last made connections
>   (see above)

read above

> Currently I just setup a BIG server instead of a cluster with a cold-standby node.

that's depends by your needs

> If I see imrovements in pgpool I'll give it a try again, but the pgpool-II 2.1b2
> version is not usable yet.
> 

pgpool 2.1b2, as the name says: it's a beta. So it's intended for 
testing purposes only. If you need a stable version you could try a 
previous one.
Said that, I can tell you that I'm using it in production environment 
with thousands of connections and, yes, it's running quite well.


Best Regards,
Simone Tregnago