erleans / pgo

Erlang Postgres client and connection pool
Apache License 2.0
80 stars 16 forks source link

function_clause error in pgo_connection #41

Closed benbro closed 2 years ago

benbro commented 4 years ago

pgo/src/pgo_connection.erl, line 119 https://github.com/erleans/pgo/blob/master/src/pgo_connection.erl#L119

** State machine <0.803.0> terminating
** Last event = {info,
                    {ssl_closed,
                        {sslsocket,
                            {gen_tcp,#Port<0.6257>,tls_connection,undefined},
                            [<0.12752.0>,<0.12751.0>]}}}
** When server state  = {enqueued,
                         {data,undefined,undefined,
                          #Ref<0.2546141266.2774349602.182528>,
                          {conn,<0.803.0>,
                           {sslsocket,
                            {gen_tcp,#Port<0.272832>,tls_connection,undefined},
                            [<0.24162.16>,<0.24160.26>]},
                           ssl,default,
                           #{<<"DateStyle">> => <<"ISO, MDY">>,
                             <<"IntervalStyle">> => <<"postgres">>,
                             <<"TimeZone">> => <<"Etc/UTC">>,
                             <<"application_name">> =>
                              <<"app@127.0.0.1">>,
                             <<"client_encoding">> => <<"UTF8">>,
                             <<"integer_datetimes">> => <<"on">>,
                             <<"is_superuser">> => <<"off">>,
                             <<"server_encoding">> => <<"UTF8">>,
                             <<"server_version">> =>
                              <<"12.2 (Ubuntu 12.2-4)">>,
                             <<"session_authorization">> => <<"app">>,
                             <<"standard_conforming_strings">> => <<"on">>},
                           true,false,[]},
                          #{database => "app",
                            host => "127.0.0.1",
                            password =>
                             "**************",
                            pool_size => 5,ssl => true,
                            ssl_options => [{verify,verify_none}],
                            user => "app"},
                          #Ref<0.3336231166.2770582461.101011>,default,
                          <0.823.0>,<0.824.0>,
                          {backoff,1000,10000,1000,normal,undefined,
                           undefined}}}
tsloughter commented 4 years ago

Thanks, that looks like another easy fix. It either needs to just ignore that message or handle it the same as EXIT:

handle_event(info, {'EXIT', Socket, _Reason}, Data=#data{conn=Socket}) ->
    %% socket died, go to disconnected state
    {next_state, disconnected, Data#data{conn=undefined},
     [{next_event, internal, connect}]}.
tsloughter commented 4 years ago

The reason I say it might be ok to ignore it is the EXIT message should already be handling this case of the socket closing.

Will definitely need a catch all at the end because if we get both these messages it means one of them will fail the function header match on Socket in the message and conn=Socket in the function header, preventing from leaking sockets and twice running moving to disconnected state and setting conn to undefined.

benbro commented 4 years ago

So which one? Ignore it or handle it the same as 'EXIT'?

tsloughter commented 4 years ago

Sorry. Both actually.

A function that handles it the same as EXIT and one that is a catch all. Because it matches on 2 Socket variables this will ensure it doesn't happen twice, so we can just handle it no matter which we get first.

tsloughter commented 2 years ago

Resolved by #58