feat(compute): Set default application_name for pgbouncer connections #9973
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When client specifies `application_name`, pgbouncer propagates it to the Postgres. Yet, if client doesn't do it, we have hard time figuring out who opens a lot of Postgres connections (including the `cloud_admin` ones). I haven't found this documented, but it looks like pgbouncer accepts standard Postgres connstring parameters in the connstring in the `[databases]` section, so put the default `application_name=pgbouncer` there. That way, we will always see who opens Postgres connections. I did tests, and if client specifies a `application_name`, pgboucner overrides this default, so it only works if it's not specified or set to blank `&application_name=` in the connection string. I think this is the last place we could potentially open some Postgres connections without `application_name`. Everything else should be either of two: 1. Direct client connections without `application_name`, but these should be strictly non`cloud_admin` ones 2. Some ad-hoc internal connections so if we will see spikes of unidentified `cloud_admin` connections, we will need to investigate it again. Fixes neondatabase/cloud#20948
tristan957
approved these changes
Dec 2, 2024
7018 tests run: 6710 passed, 0 failed, 308 skipped (full report)Flaky tests (5)Postgres 17
Postgres 16
Postgres 15
Postgres 14
Code coverage* (full report)
* collected from Rust tests only The comment gets automatically updated with the latest test results
33ea9b1 at 2024-12-02T21:57:29.993Z :recycle: |
ololobus
added a commit
that referenced
this pull request
Dec 4, 2024
We didn't have a codeowner for `/compute`, so nobody was auto-assigned for PRs like #9973 While on it: 1. Group codeowners into sections. 2. Remove control plane from the `/compute_tools` because it's primarily the internal `compute_ctl` code. 3. Add control plane (and compute) to `/libs/compute_api` because that's the shared public interface of the compute.
awarus
pushed a commit
that referenced
this pull request
Dec 5, 2024
…#9973) ## Problem When client specifies `application_name`, pgbouncer propagates it to the Postgres. Yet, if client doesn't do it, we have hard time figuring out who opens a lot of Postgres connections (including the `cloud_admin` ones). See this investigation as an example: https://neondb.slack.com/archives/C0836R0RZ0D ## Summary of changes I haven't found this documented, but it looks like pgbouncer accepts standard Postgres connstring parameters in the connstring in the `[databases]` section, so put the default `application_name=pgbouncer` there. That way, we will always see who opens Postgres connections. I did tests, and if client specifies a `application_name`, pgbouncer overrides this default, so it only works if it's not specified or set to blank `&application_name=` in the connection string. This is the last place we could potentially open some Postgres connections without `application_name`. Everything else should be either of two: 1. Direct client connections without `application_name`, but these should be strictly non-`cloud_admin` ones 2. Some ad-hoc internal connections, so if we see spikes of unidentified `cloud_admin` connections, we will need to investigate it again. Fixes neondatabase/cloud#20948
ololobus
added a commit
that referenced
this pull request
Dec 5, 2024
We didn't have a codeowner for `/compute`, so nobody was auto-assigned for PRs like #9973 While on it: 1. Group codeowners into sections. 2. Remove control plane from the `/compute_tools` because it's primarily the internal `compute_ctl` code. 3. Add control plane (and compute) to `/libs/compute_api` because that's the shared public interface of the compute.
github-merge-queue bot
pushed a commit
that referenced
this pull request
Dec 6, 2024
## Problem We didn't have a codeowner for `/compute`, so nobody was auto-assigned for PRs like #9973 ## Summary of changes While on it: 1. Group codeowners into sections. 2. Remove control plane from the `/compute_tools` because it's primarily the internal `compute_ctl` code. 3. Add control plane (and compute) to `/libs/compute_api` because that's the shared public interface of the compute.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
When client specifies
application_name, pgbouncer propagates it to the Postgres. Yet, if client doesn't do it, we have hard time figuring out who opens a lot of Postgres connections (including thecloud_adminones).See this investigation as an example: https://neondb.slack.com/archives/C0836R0RZ0D
Summary of changes
I haven't found this documented, but it looks like pgbouncer accepts standard Postgres connstring parameters in the connstring in the
[databases]section, so put the defaultapplication_name=pgbouncerthere. That way, we will always see who opens Postgres connections. I did tests, and if client specifies aapplication_name, pgbouncer overrides this default, so it only works if it's not specified or set to blank&application_name=in the connection string.This is the last place we could potentially open some Postgres connections without
application_name. Everything else should be either of two:application_name, but these should be strictly non-cloud_adminonescloud_adminconnections, we will need to investigate it again.Fixes neondatabase/cloud#20948