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

Improve heuristic to check if PG is local #39

Closed
gozdal opened this issue Apr 7, 2021 · 4 comments
Closed

Improve heuristic to check if PG is local #39

gozdal opened this issue Apr 7, 2021 · 4 comments

Comments

@gozdal
Copy link

gozdal commented Apr 7, 2021

If PostgreSQL is listening on loopback interface, but not necessarily on 127.0.0.1 then

func (c *collector) getLocal() {

fails to detect that PG is actually local.
E.g. if you have /etc/hosts with

127.0.0.1 localhost
127.0.1.1 pg

and you configure PG with

listen_addresses = 'pg'

then PG will listen on 127.0.1.1 but the TCP connection to 127.0.1.1 will appear from 127.0.0.1, i.e. inet_client_addr() will be 127.0.0.1 and inet_server_addr() will be 127.0.1.1.

Maybe a special case for 127.0.0.0/8 would be useful here?

@mdevan
Copy link
Contributor

mdevan commented Apr 8, 2021

Yes, that sounds reasonable. I suppose changing the current query from:

SELECT COALESCE(inet_client_addr() = inet_server_addr(), TRUE)

to:

SELECT COALESCE(inet_client_addr() = inet_server_addr(), TRUE) OR (inet_server_addr() << '127.0.0.0/8')

should do the trick. What do you think?

@gozdal
Copy link
Author

gozdal commented Apr 8, 2021

I wonder if there is some weird networking scenario (DNAT?) where inet_server_addr() is 127.0.0.0/8 but the client is actually connecting from outside(i.e. inet_client_addr() is not 127.0.0.0/8).
WDYT about

SELECT COALESCE(inet_client_addr() = inet_server_addr(), TRUE) OR (inet_server_addr() << '127.0.0.0/8' AND inet_client_addr() << '127.0.0.0/8')

@mdevan
Copy link
Contributor

mdevan commented Apr 10, 2021

That should reduce the false positives. Might still fail for cases like when pgmetrics connects remotely to a pooler/proxy that in turn connects to a locally-running postgres over a localhost interface.

Anyway, last one above should be good enough as a heuristic I feel. We can always add a --force-local={true|false} or some such flag later if required.

@mdevan
Copy link
Contributor

mdevan commented Apr 14, 2021

Added in commit 581da00.

@mdevan mdevan closed this as completed Apr 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants