Spring Boot 3.2.5

Logs

$ docker compose logs db -f
...
db-1  | 2024-05-16 10:18:14.746 UTC [37] LOG:  connection received: host=192.168.65.1 port=42395
db-1  | 2024-05-16 10:18:14.766 UTC [37] LOG:  connection authenticated: identity="test" method=scram-sha-256 (/var/lib/postgresql/data/pg_hba.conf:128)
db-1  | 2024-05-16 10:18:14.766 UTC [37] LOG:  connection authorized: user=test database=test
db-1  | 2024-05-16 10:18:14.769 UTC [37] LOG:  execute <unnamed>: SET extra_float_digits = 3
db-1  | 2024-05-16 10:18:14.770 UTC [37] LOG:  execute <unnamed>: SET application_name = 'PostgreSQL JDBC Driver'

Setup

application.yaml

spring:
  application:
    name: application-name-test

compose.yaml

services:
  db:
    image: postgres
    restart: always
    ports:
      - '5432:5432'
    environment:
      POSTGRES_USER: test
      POSTGRES_PASSWORD: test
      POSTGRES_DB: test
    command: ["postgres", "-c", "log_statement=all", "-c", "log_connections=true"]

---

Currently one has to explicitly configure the application name via org.springframework.boot.jdbc.parameters:

services:
  db:
    image: postgres
...
    labels:
      org.springframework.boot.jdbc.parameters: 'ApplicationName=application-name-test'

⇓

db-1  | 2024-05-16 10:21:53.323 UTC [39] LOG:  execute <unnamed>: SET application_name = 'application-name-test'

Comment From: wilkinsona

Thanks for the suggestion. I can see how this is useful in production when, presumably, you're configuring the application name on the JDBC URL. What's the benefit at development time when using Docker Compose? Do you perhaps have multiple apps sharing a compose file and the name makes each app's queries easier to identify?

Comment From: sdavids

It makes debugging easier if you have a setup with for example Keycloak, Spring Cloud Gateway, and Spring Cloud Vault all talking to the same Postgres instance provided by the compose file.

Or if you use Sharing services between multiple applications, for example two Spring Boot applications for two bounded contexts using the same Postgres instance but each with their own database.

Comment From: snicoll

Closing in favor of PR #42460, thanks again @nosan!