only reconnect if we receive EXIT from the conn pid

[aktungmak]

No description provided.

[davidw]

Do we really want that extra clause?

[aktungmak]

If we don't have that clause, then the worker will crash any time it receives a message other than the 'EXIT' from epgsql_sock. When using pgapp:with_transaction this can occur since the transaction function is run by the worker process.

[davidw]

@aktungmak is there a way to trigger that that always works, so I can test it out?

I do not like 'catch all' handlers, as they may let problems sneak in.

Thanks!

[aktungmak]

I didn't get a chance to write some proper example code to reproduce it, but essentially this is how the issue is triggered:

pgapp:with_transaction(fun() -> self() ! {'EXIT', self(), normal} end)

[davidw]

@aktungmak ok... that works. What kind of real world code was causing something like that?

[aktungmak]

The code was using a library that was spawn_linking other processes which then finished normally, and since the pgapp_worker process is trapping exits it was receiving {'EXIT', Pid, normal} messages. I wrote a bit more detail on this in issue #26.

[davidw]

Would it make sense to do something like wrap the other library with a receive looking for its exit?

[aktungmak]

We have refactored the code that was using the other library to perform the work outside the transaction now, which avoid the issue in this particular case.

[davidw]

@aktungmak would your refactoring still work if we include your patch, without the 'catchall' handle_info ?

[aktungmak]

Yep, that will be just fine 👍

[aktungmak]

The only problem will be as I mentioned above, that the worker will crash if it receives any other messages inside the transaction function (eg if a spawn_linked process finishes normally).

We are no longer doing that so its OK by me but it is good to know in future that the transaction functions should avoid doing that.