From: | Amjith Ramanujam <amjith(dot)r(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Client deadlocks when connecting via ssl |
Date: | 2014-10-09 18:33:43 |
Message-ID: | CAHUL3dq_+cNY47XFfyRFnNuuGt8KduCskuAofFLX6PxAv8OXKw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Thu, Oct 9, 2014 at 7:18 AM, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
wrote:
> Thanks, I was able to easily reproduce this with the script.
>
I'm glad you were able to reproduce it.
> I'm not sure what to do about this. We could not unregister the callbacks,
> when the last libpq connection is closed, but there's a comment in
> destroy_ssl_system explaining why that would be bad (if libpq is later
> unloaded, the callback pointers would be left dangling). Perhaps we could
> leave the callbacks registered when the last connection is closed, and add
> a _fini() function that unregisters them when the library is unloaded. I'm
> not sure how portable that is, though.
>
> Another idea is to check if any of the locks are held, when the last libpq
> connection is closed, and leave the callbacks in place if there are.
>
I'm not informed enough to suggest a solution in this case. But I'll be
glad to stress test it again if a patch were made available.
Let me know if I could be of more help.
Cheers!
Amjith
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2014-10-09 19:36:39 | schema-only -n option in pg_restore fails |
Previous Message | Michiel Lange | 2014-10-09 18:03:07 | Re: BUG #11603: replication, pg_basebackup and high load |