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

Extra options per connection endpoint are ignored #730

Open
msfstef opened this issue Feb 3, 2025 · 2 comments
Open

Extra options per connection endpoint are ignored #730

msfstef opened this issue Feb 3, 2025 · 2 comments
Labels

Comments

@msfstef
Copy link

msfstef commented Feb 3, 2025

Elixir version

1.18.1

Database and Version

17

Postgrex Version

0.19.0

Current behavior

Specifying the start_link connection options as:

endpoints: [
        {hostname, port, socket_options: [:inet6]},
        {hostname, port, socket_options: [:inet]}
]

Results in a warning

[warning] Returning a triplet from :endpoints is deprecated, the server name indicator is automatically set based on the hostname if SSL is enabled

And the options are not respected - and looking at the source they seem to be completely discarded:

{hostname, port, _extra_opts} ->
Logger.warning(
"Returning a triplet from :endpoints is deprecated, " <>
"the server name indicator is automatically set based on the hostname if SSL is enabled"
)

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?

@josevalim
Copy link
Member

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.

@msfstef
Copy link
Author

msfstef commented Feb 3, 2025

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 endpoints option.

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

msfstef added a commit to electric-sql/electric that referenced this issue Feb 3, 2025
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants