mirror of
https://github.com/neondatabase/neon.git
synced 2026-01-04 20:12:54 +00:00
9a4157dadb
## 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
This directory contains files that are needed to build the compute images, or included in the compute images.
compute-node.Dockerfile To build the compute image
vm-image-spec.yaml Instructions for vm-builder, to turn the compute-node image into corresponding vm-compute-node image.
etc/ Configuration files included in /etc in the compute image
patches/ Some extensions need to be patched to work with Neon. This directory contains such patches. They are applied to the extension sources in compute-node.Dockerfile
In addition to these, postgres itself, the neon postgres extension, and compute_ctl are built and copied into the compute image by compute-node.Dockerfile.