-
Notifications
You must be signed in to change notification settings - Fork 277
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
Extra options per connection endpoint are ignored #730
Comments
It could be reinstated. Can you please provide more details on what you want to achieve? The reason it was removed is because we have better defaults that work across different situations. For example, it may work now without additional extra options. Meanwhile I will update the docs. |
The main reason we were looking at the endpoints with extra options per endpoint was to be able to always try to connect using IPv6 and fallback to IPv4 if the former is not resolvable. See erlang/otp#8548 for a more general description of the issue, where someone suggested Postgrex's The ideal situation would be for a database URL to be provided, and for no specification of whether we should use IPv6 or IPv4 to connect to it to be needed and for the connection to succeed, for IPv4-only, IPv6-only, and with a preference for IPv6 if both are available. edit: there is a similar situation with wanting to try different SSL configurations and having fallbacks there, but less important than the IPv6 to IPv4 fallback described above |
When `DATABASE_USE_IPV6` is enabled, but the provided DB URL has no resolvable IPv6 address (no AAAA record), naively fallback to IPv4. A more general discussion on this fallback behaviour for Erlang's networking stack can be found here erlang/otp#8548 Ideally we would be able to handle this sort of fallback directly with Postgrex, and it used to have the possibility to specify multiple endpoints with different options that it would try sequentially, but it is no longer supported. I have opened an issue to see if there is a potential solution to this that can be supported by Postgrex directly elixir-ecto/postgrex#730 Perhaps once we are happy with both IPv6 and IPv4 being supported out of the box we can remove the `DATABASE_USE_IPV6` option and always default to supporting it, but I think it's safer to explore this a bit further. This PR introduces a naive fix that does not cover all possible failure and fallback cases, but unblocks the basic case of AAAA records missing while also supporting IPv6.
Elixir version
1.18.1
Database and Version
17
Postgrex Version
0.19.0
Current behavior
Specifying the
start_link
connection options as:Results in a warning
And the options are not respected - and looking at the source they seem to be completely discarded:
postgrex/lib/postgrex/protocol.ex
Lines 192 to 196 in 34a57fe
Expected behavior
We want to be able to fallback from IPv6 to IPv4, and potentially also try different SSL options, and the
endpoints
option is currently documented to accept extra options.If the library had the documented behaviour it would be very convenient for implementing fallbacks in configuration options - is the lack of support of options per endpoint an intentional decision, and would it potentially be reinstated?
The text was updated successfully, but these errors were encountered: