[pgpool-general: 9266] Re: Segmentation fault during shutdown

[Tatsuo Ishii]

> Hi Emond,
> 
>> Hi,
>> 
>> Your explanation makes sense. In the original backtrace, you can see that
>> the signal handler is started from memset, which is called from
>> pool_init_cp. The thing I'm worried about with your patch, is that this
>> will cause pgpool to no longer inform postgresql that it's about to close
>> the connection. I don't know how postgresql handles such termination
>> messages, but it would make sense that it frees resources on receiving a
>> termination message. These resources will most likely also be freed when
>> the tcp connection is closed, but what if for some reason that fails? That
>> would cause the tcp connection to become stale and keep the resources
>> allocated for a very long time until the tcp connection times out (probably
>> 2 hours).
> 
> PostgreSQL handles both the terminate message and broken socket (EOF
> upon recv(2)) in same way. From src/backend/tcop/postgres.c around
> line 4993:
> 
> 				/*
> 				 * 'X' means that the frontend is closing down the socket. EOF
> 				 * means unexpected loss of frontend connection. Either way,
> 				 * perform normal shutdown.
> 				 */
> 			case EOF:
> 
> 				/* for the cumulative statistics system */
> 				pgStatSessionEndCause = DISCONNECT_CLIENT_EOF;
> 
> 				/* FALLTHROUGH */
> 
> 			case PqMsg_Terminate:
> 
> 				/*
> 
> Note that "PqMsg_Terminate" is actually 'X' (terminate message). So
> there's no fear that some resouces remain upon broken connection
> scenario (EOF). However, problem is, it may take long time before
> PostgreSQL notices EOF if tcp_keepalives_idle is not set (as you said
> if it's not set, most system default is likely 2 hours).
> 
>> What if pool_init_cp would set a flag to indicates a successful
>> init. close_all_backend_connections could then check this flag and only
>> close the connections if this flag is set. I don't know if is actually
>> possible, because I'm a Java developer and things work quite different
>> there. But IMHO, it makes sense to at least try to close the connections
>> from the side of pgpool if this is possible.
> 
> Sounds like a good idea. I will revert the previous commit and try to
> implement another patch for this.

v2 patch attached.

Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v2_fix_segfault.patch
Type: text/x-patch
Size: 789 bytes
Desc: not available
URL: <http://www.pgpool.net/pipermail/pgpool-general/attachments/20241109/247766b1/attachment.bin>