[Pgpool-general] pgpool 2.2.4: DEALLOCATED children

[Glyn Astill]

--- On Wed, 23/9/09, Tatsuo Ishii <ishii at sraoss.co.jp> wrote:
> > Hi
> > 
> > We applied the patch with the same result. After some
> seconds child  
> > processes go into DEALLOCATE state until pgpool gets
> completly hang.
> > 
> > root   
>    592   569  4 23:31
> ?        00:00:57 pgpool: sess
> sess  
> > 127.0.0.1(56552) DEALLOCATE
> > root   
>    597   569  0 23:31
> ?        00:00:03 pgpool: sess
> sess  
> > 127.0.0.1(37107) DEALLOCATE
> > root   
>    603   569  4 23:31
> ?        00:00:57 pgpool: sess
> sess  
> > 127.0.0.1(41935) DEALLOCATE
> > root   
>    615   569  3 23:31
> ?        00:00:47 pgpool: sess
> sess  
> > 127.0.0.1(42742) DEALLOCATE
> > root   
>    625   569  0 23:31
> ?        00:00:09 pgpool: sess
> sess  
> > 127.0.0.1(34685) DEALLOCATE
> > root     
> 1173   569  4 23:36 ?   
>     00:00:41 pgpool: sess sess  
> > 127.0.0.1(47999) DEALLOCATE
> > root     
> 1200   569  1 23:36 ?   
>     00:00:11 pgpool: sess sess  
> > 127.0.0.1(37230) DEALLOCATE
> > root     
> 1490   569  7 23:38 ?   
>     00:00:57 pgpool: sess sess  
> > 127.0.0.1(60995) DEALLOCATE
> > root     
> 1512   569  3 23:38 ?   
>     00:00:25 pgpool: sess sess  
> > 127.0.0.1(38378) DEALLOCATE
> > root     
> 1712   569  4 23:42 ?   
>     00:00:25 pgpool: sess sess  
> > 127.0.0.1(45094) DEALLOCATE
> > root     
> 1715   569  4 23:42 ?   
>     00:00:23 pgpool: sess sess  
> > 127.0.0.1(34418) DEALLOCATE
> > 
> > 
> > i attached the complete log for one of these
> processes.
> > 
> > 
> > Please any test we can do to help the analsys just let
> us know.
> 
> It seems cause of this is, pgpool sends BEGIN to PostgreSQL
> and
> PostgreSQL replies ERROR for unknown reason. I need to know
> why
> PostgreSQL emits ERROR. Can you find error messages in the
> PostgreSQL
> log?


We saw a similar(ish) issue here where a pgpool backend went into an aparent infinite loop sending the same dealocate statement to the postgres server, but I couldn't reproduce it at the time.

However this was on 2.2.3, and at the same time as moving to 2.2.3 I changed reset_query_list to 'ABORT; DISCARD ALL'.

The next day 2.2.4 was released so we upgraded and I switched reset_query_list back to 'ABORT; RESET ALL; SET SESSION AUTHORIZATION DEFAULT'.

I've not seen any issues since, using 'ABORT; DISCARD ALL' has always caused problems for me though.