Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix function_clause on set_succeeded_or_within_failed_transaction #41

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion src/pgsql_connection.erl
Original file line number Diff line number Diff line change
Expand Up @@ -774,8 +774,9 @@ pgsql_simple_query(Query, QueryOptions, Timeout, From, #state{socket = {SockModu
% (unless it is a rollback).
% If set succeeded within a transaction, but the query failed, the reset may
% fail but set only applies to the transaction anyway.
-spec set_succeeded_or_within_failed_transaction({set, []} | {error, pgsql_error:pgsql_error()}) -> boolean().
-spec set_succeeded_or_within_failed_transaction({set, []} | {error, pgsql_error:pgsql_error()}|{error,closed}) -> boolean().
set_succeeded_or_within_failed_transaction({set, []}) -> true;
set_succeeded_or_within_failed_transaction({error, closed}) -> true;
set_succeeded_or_within_failed_transaction({error, {pgsql_error, _} = Error}) ->
pgsql_error:is_in_failed_sql_transaction(Error).

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is the result true instead of pgsql_error:is_in_failed_sql_transaction(Error)?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to the definition of is_in_failed_sql_transaction in pgsql_error.erl:
is_in_failed_sql_transaction({pgsql_error, Fields}) ->
{code, <<"25P02">>} =:= lists:keyfind(code, 1, Fields).
{error, closed} wouldn't match. Also the comment on the function set_succeeded_or_within_failed_transaction states that it should always return true.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But in the definition of pgsql_error:is_in_failed_sql_transaction/1 we can see that it might not return true... (Also, if set_succeeded_or_within_failed_transaction/1 should always return true then it's spec ought to say that instead of boolean())

But anyhow, I think I see what you're saying: if we're in an aborted transaction then the result of this function is true. You're suggesting that having the connection drop is analogous to the transaction aborting. That makes sense to me; the comment

% If set failed because the transaction was aborted, the query will fail

seems like it should apply just as well to the connection dropping.

I feel convinced that this solution is reasonable. :) Were you able to test this code?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the moment I haven't been able to reproduce the exact scenario where it happens


Expand Down