Race condition on `Process.unlink` when `mode` is `transaction` about supavisor HOT 4 CLOSED

I believe that the db_handler should reset the "caller" value after ready_for_query because there can be a situation where the client is linked with another database process, and the old one will continue to send messages.

from supavisor.

@abc3 I can take a stab at this with a bit more info. Are you imagining that while the Client may have "moved on" and is now associated with a new db_handler, the old db_handler - which still has messages incoming for the Client - would stay associated to the Client?

The difficulty I see is I'm not sure how we'll know that the db_handler is done responding to a Client. In a pipelined query, as I mentioned above, we have one incoming request from the Client that is going to instigate two separate db_handler responses, the first of which contains a ready_for_query.

from supavisor.

Sorry for the late response, it has been a tough week. According to the PostgreSQL documentation, ready_for_query indicates that the cycle is finished and the current database pool is ready for new queries.

So, after receiving this message, we can be sure that the client's query is finished. We should then clean up data.caller to avoid scenarios where DbHandler might receive an asynchronous message and forward it to the last linked client.

Would you like to implement this change?

from supavisor.

fixed in #207

from supavisor.