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

Support socket connections for local patroni instance #61

Closed
jberkus opened this issue Oct 12, 2015 · 5 comments
Closed

Support socket connections for local patroni instance #61

jberkus opened this issue Oct 12, 2015 · 5 comments

Comments

@jberkus
Copy link
Contributor

jberkus commented Oct 12, 2015

Currently, the local patroni instance can only connect using TCP. We should support local unix socket connections as well; that's both faster and more secure.

This will require some replumbing, which I regard as a cleanup anyway. Currently, we read config information, use that to create a URL, then parse that URL to get the config information back. This seems unnecessarily ornate; we should either use URLs in the config in the first place, or we should avoid this whole unnecessary step and use the config fields directly. For backwards-compatibility reasons, I plan to use the latter path.

I'll also use a file path for the socket interface if that's preferred by the user. It should be simple to differentiate this from an IPv4/v6 address.

I plan to do this in the next couple of days, so let me know if you have comments on the design.

@LappleApple
Copy link
Contributor

@jberkus Hi, did you finish or are you still working on this one? Wondering if we can resolve this issue. cc @feikesteenbergen

@LappleApple
Copy link
Contributor

@alexeyklyukin @feikesteenbergen @CyberDem0n @jberkus One more time: What's the status of this Issue? We could add a "Help Wanted" label if it's unfinished and still in scope.

@rsiera
Copy link

rsiera commented Jan 9, 2017

@LappleApple can I work on this enhancement, or anyone else is involved in task at this moment ?

@alexeyklyukin
Copy link
Contributor

@rsiera yes, sure. I'd focus on supporting UNIX sockets instead of hosts in the configuration and would not change the way we work with URLs at the moment, in particular, avoid changing configuration parameters from the dictionary of keys to the URLs. Also, be careful when parsing URLs, as we supply an additional {{application_name}} parameter in dcs/init.py, that carries an api URL.

CyberDem0n pushed a commit that referenced this issue Jun 21, 2017
This feature is enabled by default. If the `unix_socket_directories` is
defined and non empty, Patroni will use the first value from it to
connect to the local postgres cluster. Also unix socket will be used
when running `post_bootstrap` (`post_init`) script.

Set `postgresql.use_unix_socket: false` if you want to disable it.

Solves: #61

In addition to mentioned above, this commit solves couple of bugs:
* manual failover with pg_rewind in a pause state was broken
* psycopg2 (or libpq, I am not really sure what exactly) doesn't mark
  cusros connection as closed when we use unix socket and there is an
  OperationalError occurs. We will close such connection on our own.
CyberDem0n added a commit that referenced this issue Jun 22, 2017
For backward compatibility this feature is not enabled by default. To enable it you have to set `postgresql.use_unix_socket: true`.
If feature is enable, and `unix_socket_directories` is defined and non empty, Patroni will use the first suitable value from it to connect to the local postgres cluster.
If the `unix_socket_directories` is not defined, Patroni will assume that default value should be used and will not pass `host` to command line arguments and omit it from connection url.

Solves: #61

In addition to mentioned above, this commit solves couple of bugs:
* manual failover with pg_rewind in a pause state was broken
* psycopg2 (or libpq, I am not really sure what exactly) doesn't mark cursors connection as closed when we use unix socket and there is an `OperationalError` occurs. We will close such connection on our own.
@CyberDem0n
Copy link
Collaborator

closed by #457

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants