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

Emond Papegaaij emond.papegaaij at gmail.com
Mon Nov 11 18:25:16 JST 2024


Op za 9 nov 2024 om 08:56 schreef Tatsuo Ishii <ishii at postgresql.org>:

> > 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:
> > 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).
>

 That was exactly what I was afraid of. It's probably not going to happen
often, but for these cases, it's better to be on the safe side.

>> 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.
>

Thanks, I've added the patch to our build system. As this crash is very
rare, all I can do is verify the correct working of pgpool with this patch
(and I see no reason why it would not work). Even if the issue is not
fixed, it may take months to resurface.

Best regards,
Emond
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pgpool.net/pipermail/pgpool-general/attachments/20241111/5ffc4b87/attachment.htm>


More information about the pgpool-general mailing list