-
Notifications
You must be signed in to change notification settings - Fork 63
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
Comments
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? |
I wonder if there is some weird networking scenario (DNAT?) where 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') |
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 |
Added in commit 581da00. |
If PostgreSQL is listening on loopback interface, but not necessarily on
127.0.0.1
thenpgmetrics/collector/collect.go
Line 625 in 1d87609
fails to detect that PG is actually local.
E.g. if you have
/etc/hosts
withand you configure PG with
then PG will listen on
127.0.1.1
but the TCP connection to127.0.1.1
will appear from127.0.0.1
, i.e.inet_client_addr()
will be127.0.0.1
andinet_server_addr()
will be127.0.1.1
.Maybe a special case for
127.0.0.0/8
would be useful here?The text was updated successfully, but these errors were encountered: