4 ms·
It is a common solution, but losing track of where connections are from can be a pretty big price to pay. I am painfully aware of this due to a situation where
by btilly 6y ago
It is a common solution, but losing track of where connections are from can be a pretty big price to pay.
I am painfully aware of this due to a situation where a rogue machine with an out of date version of software kept making unwanted updates. It literally took months of off and on searching to locate the machine. And the most irritating thing was that Postgres internally contains all of the tools that we needed to trace where connections came from..which is how we knew that it was connecting through pgbouncer.
- asah 6y agoDumb q: pgbouncer didn't have logs? There was no way to modify the connection or request to add identifying info? Genuinely curious...
- btilly 6y agoIt had logs, but they were not useful. However reading docs, it looks like my complaint is dated. In version 1.6 (released in 2015) they added the application_name_add_host parameter which sticks the client ip and port to application_name. This allows bad queries to be tracked back to the source machine. I wish I had had that feature available to me when I needed it...