langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-21 20:15:31 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

Operational error when using managed PostgreSQL caused by too many concurrent connections #8352

New Issue
Closed
opened 2026-02-21 18:25:12 -05:00 by yindo · 3 comments
yindo commented 2026-02-21 18:25:12 -05:00
Owner
Copy Link
Copy Source

Originally created by @ytjhai on GitHub (Feb 17, 2025).

Self Checks

  • This is only for bug report, if you would like to ask a question, please head to Discussions.
  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
  • [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:）
  • Please do not modify this template :) and fill in all the required fields.

Dify version

0.15.3

Cloud or Self Hosted

Self Hosted (Docker), Cloud

Steps to reproduce

Background

I made small modifications to the docker-compose.yml that may be relevant to this issue. Below are the docker services that I'm using with Digital Ocean and their managed database service. This issue started occurring after upgrading to 0.15.3 from 0.14.1. For the vector database, the qdrant profile is used.

services:
  # API service
  api:
    image: langgenius/dify-api:0.15.3
    restart: always
    environment:
      # Use the shared environment variables.
      <<: *shared-api-worker-env
      # Startup mode, 'api' starts the API server.
      MODE: api
      SENTRY_DSN: ${API_SENTRY_DSN:-}
      SENTRY_TRACES_SAMPLE_RATE: ${API_SENTRY_TRACES_SAMPLE_RATE:-1.0}
      SENTRY_PROFILES_SAMPLE_RATE: ${API_SENTRY_PROFILES_SAMPLE_RATE:-1.0}
      PLUGIN_MAX_PACKAGE_SIZE: ${PLUGIN_MAX_PACKAGE_SIZE:-52428800}
      INNER_API_KEY_FOR_PLUGIN: ${PLUGIN_DIFY_INNER_API_KEY:-QaHbTe77CtuXmsfyhR7+vRjI/+XbV1AaFy691iy+kGDv2Jvy0/eAh8Y1}
    depends_on:
      - redis
    volumes:
      # Mount the storage directory to the container, for storing user files.
      - ./volumes/app/storage:/app/api/storage
    networks:
      - ssrf_proxy_network
      - default

  # worker service
  # The Celery worker for processing the queue.
  worker:
    image: langgenius/dify-api:0.15.3
    restart: always
    environment:
      # Use the shared environment variables.
      <<: *shared-api-worker-env
      # Startup mode, 'worker' starts the Celery worker for processing the queue.
      MODE: worker
      SENTRY_DSN: ${API_SENTRY_DSN:-}
      SENTRY_TRACES_SAMPLE_RATE: ${API_SENTRY_TRACES_SAMPLE_RATE:-1.0}
      SENTRY_PROFILES_SAMPLE_RATE: ${API_SENTRY_PROFILES_SAMPLE_RATE:-1.0}
      PLUGIN_MAX_PACKAGE_SIZE: ${PLUGIN_MAX_PACKAGE_SIZE:-52428800}
      INNER_API_KEY_FOR_PLUGIN: ${PLUGIN_DIFY_INNER_API_KEY:-QaHbTe77CtuXmsfyhR7+vRjI/+XbV1AaFy691iy+kGDv2Jvy0/eAh8Y1}
    depends_on:
      - redis
    volumes:
      # Mount the storage directory to the container, for storing user files.
      - ./volumes/app/storage:/app/api/storage
    networks:
      - ssrf_proxy_network
      - default

  # Frontend web application.
  web:
    image: langgenius/dify-web:0.15.3
    restart: always
    environment:
      CONSOLE_API_URL: ${CONSOLE_API_URL:-}
      APP_API_URL: ${APP_API_URL:-}
      SENTRY_DSN: ${WEB_SENTRY_DSN:-}
      NEXT_TELEMETRY_DISABLED: ${NEXT_TELEMETRY_DISABLED:-0}
      TEXT_GENERATION_TIMEOUT_MS: ${TEXT_GENERATION_TIMEOUT_MS:-60000}
      CSP_WHITELIST: ${CSP_WHITELIST:-}
      MARKETPLACE_API_URL: ${MARKETPLACE_API_URL:-https://marketplace.dify.ai}
      MARKETPLACE_URL: ${MARKETPLACE_URL:-https://marketplace.dify.ai}
      TOP_K_MAX_VALUE: ${TOP_K_MAX_VALUE:-}
      INDEXING_MAX_SEGMENTATION_TOKENS_LENGTH: ${INDEXING_MAX_SEGMENTATION_TOKENS_LENGTH:-}

  # # The postgres database.
  # db:
  #   image: postgres:15-alpine
  #   restart: always
  #   environment:
  #     PGUSER: ${PGUSER:-postgres}
  #     POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:-difyai123456}
  #     POSTGRES_DB: ${POSTGRES_DB:-dify}
  #     PGDATA: ${PGDATA:-/var/lib/postgresql/data/pgdata}
  #   command: >
  #     postgres -c 'max_connections=${POSTGRES_MAX_CONNECTIONS:-100}'
  #              -c 'shared_buffers=${POSTGRES_SHARED_BUFFERS:-128MB}'
  #              -c 'work_mem=${POSTGRES_WORK_MEM:-4MB}'
  #              -c 'maintenance_work_mem=${POSTGRES_MAINTENANCE_WORK_MEM:-64MB}'
  #              -c 'effective_cache_size=${POSTGRES_EFFECTIVE_CACHE_SIZE:-4096MB}'
  #   volumes:
  #     - ./volumes/db/data:/var/lib/postgresql/data
  #   healthcheck:
  #     test: ['CMD', 'pg_isready']
  #     interval: 1s
  #     timeout: 3s
  #     retries: 30

  # The redis cache.
  redis:
    image: redis:6-alpine
    restart: always
    environment:
      REDISCLI_AUTH: ${REDIS_PASSWORD:-difyai123456}
    volumes:
      # Mount the redis data directory to the container.
      - ./volumes/redis/data:/data
    # Set the redis password when startup redis server.
    command: redis-server --requirepass ${REDIS_PASSWORD:-difyai123456}
    healthcheck:
      test: [ 'CMD', 'redis-cli', 'ping' ]

  # The DifySandbox
  sandbox:
    image: langgenius/dify-sandbox:0.2.10
    restart: always
    environment:
      # The DifySandbox configurations
      # Make sure you are changing this key for your deployment with a strong key.
      # You can generate a strong key using `openssl rand -base64 42`.
      API_KEY: ${SANDBOX_API_KEY:-dify-sandbox}
      GIN_MODE: ${SANDBOX_GIN_MODE:-release}
      WORKER_TIMEOUT: ${SANDBOX_WORKER_TIMEOUT:-15}
      ENABLE_NETWORK: ${SANDBOX_ENABLE_NETWORK:-true}
      HTTP_PROXY: ${SANDBOX_HTTP_PROXY:-http://ssrf_proxy:3128}
      HTTPS_PROXY: ${SANDBOX_HTTPS_PROXY:-http://ssrf_proxy:3128}
      SANDBOX_PORT: ${SANDBOX_PORT:-8194}
    volumes:
      - ./volumes/sandbox/dependencies:/dependencies
    healthcheck:
      test: [ 'CMD', 'curl', '-f', 'http://localhost:8194/health' ]
    networks:
      - ssrf_proxy_network

  # plugin daemon
  plugin_daemon:
    image: langgenius/dify-plugin-daemon:latest-local
    restart: always
    environment:
      # Use the shared environment variables.
      <<: *shared-api-worker-env
      DB_DATABASE: ${DB_PLUGIN_DATABASE:-dify_plugin}
      SERVER_PORT: ${PLUGIN_DAEMON_PORT:-5002}
      SERVER_KEY: ${PLUGIN_DAEMON_KEY:-lYkiYYT6owG+71oLerGzA7GXCgOT++6ovaezWAjpCjf+Sjc3ZtU+qUEi}
      MAX_PLUGIN_PACKAGE_SIZE: ${PLUGIN_MAX_PACKAGE_SIZE:-52428800}
      PPROF_ENABLED: ${PLUGIN_PPROF_ENABLED:-false}
      DIFY_INNER_API_URL: ${PLUGIN_DIFY_INNER_API_URL:-http://api:5001}
      DIFY_INNER_API_KEY: ${INNER_API_KEY_FOR_PLUGIN:-QaHbTe77CtuXmsfyhR7+vRjI/+XbV1AaFy691iy+kGDv2Jvy0/eAh8Y1}
      PLUGIN_REMOTE_INSTALLING_HOST: ${PLUGIN_REMOTE_INSTALL_HOST:-0.0.0.0}
      PLUGIN_REMOTE_INSTALLING_PORT: ${PLUGIN_REMOTE_INSTALL_PORT:-5003}
      PLUGIN_WORKING_PATH: ${PLUGIN_WORKING_PATH:-/app/storage/cwd}
      FORCE_VERIFYING_SIGNATURE: ${FORCE_VERIFYING_SIGNATURE:-true}
    ports:
      - "${EXPOSE_PLUGIN_DEBUGGING_PORT:-5003}:${PLUGIN_DEBUGGING_PORT:-5003}"
    volumes:
      - ./volumes/plugin_daemon:/app/storage


  # ssrf_proxy server
  # for more information, please refer to
  # https://docs.dify.ai/learn-more/faq/install-faq#id-18.-why-is-ssrf_proxy-needed
  ssrf_proxy:
    image: ubuntu/squid:latest
    restart: always
    volumes:
      - ./ssrf_proxy/squid.conf.template:/etc/squid/squid.conf.template
      - ./ssrf_proxy/docker-entrypoint.sh:/docker-entrypoint-mount.sh
    entrypoint: [ 'sh', '-c', "cp /docker-entrypoint-mount.sh /docker-entrypoint.sh && sed -i 's/\r$$//' /docker-entrypoint.sh && chmod +x /docker-entrypoint.sh && /docker-entrypoint.sh" ]
    environment:
      # pls clearly modify the squid env vars to fit your network environment.
      HTTP_PORT: ${SSRF_HTTP_PORT:-3128}
      COREDUMP_DIR: ${SSRF_COREDUMP_DIR:-/var/spool/squid}
      REVERSE_PROXY_PORT: ${SSRF_REVERSE_PROXY_PORT:-8194}
      SANDBOX_HOST: ${SSRF_SANDBOX_HOST:-sandbox}
      SANDBOX_PORT: ${SANDBOX_PORT:-8194}
    networks:
      - ssrf_proxy_network
      - default

Description of behavior

When I tried to upload a new document a second time, I received an Operational Error from the psycopg2 library. The error message was FATAL: remaining connection slots are reserved for roles with the SUPERUSER attribute. Background on this error: {link to additional documentation}. The additional documentation link pointed to this page: https://docs.sqlalchemy.org/en/20/errors.html#error-e3q8

Upon further investigation, when debugging this and checking active connections, the database showed several long-running queries under "ROLLBACK" and "COMMIT" that were hogging up the allocated connections. Although I'm not sure of the root cause, this may be related to the change regarding the dify-plugin-daemon. I'm not sure if this is required in 0.15.3 but it did get errors when spinning up the updated version. Some more guidance in the documentation about this dify-plugin-daemon would be helpful.

✔️ Expected Behavior

Uploading and embedding a new document to just work like before in 0.14.1

❌ Actual Behavior

No response

Originally created by @ytjhai on GitHub (Feb 17, 2025). ### Self Checks - [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report (我已阅读并同意 [Language Policy](https://github.com/langgenius/dify/issues/1542)). - [x] [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:） - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 0.15.3 ### Cloud or Self Hosted Self Hosted (Docker), Cloud ### Steps to reproduce **Background** I made small modifications to the `docker-compose.yml` that may be relevant to this issue. Below are the docker services that I'm using with Digital Ocean and their managed database service. This issue started occurring after upgrading to 0.15.3 from 0.14.1. For the vector database, the qdrant profile is used. ```yaml services: # API service api: image: langgenius/dify-api:0.15.3 restart: always environment: # Use the shared environment variables. <<: *shared-api-worker-env # Startup mode, 'api' starts the API server. MODE: api SENTRY_DSN: ${API_SENTRY_DSN:-} SENTRY_TRACES_SAMPLE_RATE: ${API_SENTRY_TRACES_SAMPLE_RATE:-1.0} SENTRY_PROFILES_SAMPLE_RATE: ${API_SENTRY_PROFILES_SAMPLE_RATE:-1.0} PLUGIN_MAX_PACKAGE_SIZE: ${PLUGIN_MAX_PACKAGE_SIZE:-52428800} INNER_API_KEY_FOR_PLUGIN: ${PLUGIN_DIFY_INNER_API_KEY:-QaHbTe77CtuXmsfyhR7+vRjI/+XbV1AaFy691iy+kGDv2Jvy0/eAh8Y1} depends_on: - redis volumes: # Mount the storage directory to the container, for storing user files. - ./volumes/app/storage:/app/api/storage networks: - ssrf_proxy_network - default # worker service # The Celery worker for processing the queue. worker: image: langgenius/dify-api:0.15.3 restart: always environment: # Use the shared environment variables. <<: *shared-api-worker-env # Startup mode, 'worker' starts the Celery worker for processing the queue. MODE: worker SENTRY_DSN: ${API_SENTRY_DSN:-} SENTRY_TRACES_SAMPLE_RATE: ${API_SENTRY_TRACES_SAMPLE_RATE:-1.0} SENTRY_PROFILES_SAMPLE_RATE: ${API_SENTRY_PROFILES_SAMPLE_RATE:-1.0} PLUGIN_MAX_PACKAGE_SIZE: ${PLUGIN_MAX_PACKAGE_SIZE:-52428800} INNER_API_KEY_FOR_PLUGIN: ${PLUGIN_DIFY_INNER_API_KEY:-QaHbTe77CtuXmsfyhR7+vRjI/+XbV1AaFy691iy+kGDv2Jvy0/eAh8Y1} depends_on: - redis volumes: # Mount the storage directory to the container, for storing user files. - ./volumes/app/storage:/app/api/storage networks: - ssrf_proxy_network - default # Frontend web application. web: image: langgenius/dify-web:0.15.3 restart: always environment: CONSOLE_API_URL: ${CONSOLE_API_URL:-} APP_API_URL: ${APP_API_URL:-} SENTRY_DSN: ${WEB_SENTRY_DSN:-} NEXT_TELEMETRY_DISABLED: ${NEXT_TELEMETRY_DISABLED:-0} TEXT_GENERATION_TIMEOUT_MS: ${TEXT_GENERATION_TIMEOUT_MS:-60000} CSP_WHITELIST: ${CSP_WHITELIST:-} MARKETPLACE_API_URL: ${MARKETPLACE_API_URL:-https://marketplace.dify.ai} MARKETPLACE_URL: ${MARKETPLACE_URL:-https://marketplace.dify.ai} TOP_K_MAX_VALUE: ${TOP_K_MAX_VALUE:-} INDEXING_MAX_SEGMENTATION_TOKENS_LENGTH: ${INDEXING_MAX_SEGMENTATION_TOKENS_LENGTH:-} # # The postgres database. # db: # image: postgres:15-alpine # restart: always # environment: # PGUSER: ${PGUSER:-postgres} # POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:-difyai123456} # POSTGRES_DB: ${POSTGRES_DB:-dify} # PGDATA: ${PGDATA:-/var/lib/postgresql/data/pgdata} # command: > # postgres -c 'max_connections=${POSTGRES_MAX_CONNECTIONS:-100}' # -c 'shared_buffers=${POSTGRES_SHARED_BUFFERS:-128MB}' # -c 'work_mem=${POSTGRES_WORK_MEM:-4MB}' # -c 'maintenance_work_mem=${POSTGRES_MAINTENANCE_WORK_MEM:-64MB}' # -c 'effective_cache_size=${POSTGRES_EFFECTIVE_CACHE_SIZE:-4096MB}' # volumes: # - ./volumes/db/data:/var/lib/postgresql/data # healthcheck: # test: ['CMD', 'pg_isready'] # interval: 1s # timeout: 3s # retries: 30 # The redis cache. redis: image: redis:6-alpine restart: always environment: REDISCLI_AUTH: ${REDIS_PASSWORD:-difyai123456} volumes: # Mount the redis data directory to the container. - ./volumes/redis/data:/data # Set the redis password when startup redis server. command: redis-server --requirepass ${REDIS_PASSWORD:-difyai123456} healthcheck: test: [ 'CMD', 'redis-cli', 'ping' ] # The DifySandbox sandbox: image: langgenius/dify-sandbox:0.2.10 restart: always environment: # The DifySandbox configurations # Make sure you are changing this key for your deployment with a strong key. # You can generate a strong key using `openssl rand -base64 42`. API_KEY: ${SANDBOX_API_KEY:-dify-sandbox} GIN_MODE: ${SANDBOX_GIN_MODE:-release} WORKER_TIMEOUT: ${SANDBOX_WORKER_TIMEOUT:-15} ENABLE_NETWORK: ${SANDBOX_ENABLE_NETWORK:-true} HTTP_PROXY: ${SANDBOX_HTTP_PROXY:-http://ssrf_proxy:3128} HTTPS_PROXY: ${SANDBOX_HTTPS_PROXY:-http://ssrf_proxy:3128} SANDBOX_PORT: ${SANDBOX_PORT:-8194} volumes: - ./volumes/sandbox/dependencies:/dependencies healthcheck: test: [ 'CMD', 'curl', '-f', 'http://localhost:8194/health' ] networks: - ssrf_proxy_network # plugin daemon plugin_daemon: image: langgenius/dify-plugin-daemon:latest-local restart: always environment: # Use the shared environment variables. <<: *shared-api-worker-env DB_DATABASE: ${DB_PLUGIN_DATABASE:-dify_plugin} SERVER_PORT: ${PLUGIN_DAEMON_PORT:-5002} SERVER_KEY: ${PLUGIN_DAEMON_KEY:-lYkiYYT6owG+71oLerGzA7GXCgOT++6ovaezWAjpCjf+Sjc3ZtU+qUEi} MAX_PLUGIN_PACKAGE_SIZE: ${PLUGIN_MAX_PACKAGE_SIZE:-52428800} PPROF_ENABLED: ${PLUGIN_PPROF_ENABLED:-false} DIFY_INNER_API_URL: ${PLUGIN_DIFY_INNER_API_URL:-http://api:5001} DIFY_INNER_API_KEY: ${INNER_API_KEY_FOR_PLUGIN:-QaHbTe77CtuXmsfyhR7+vRjI/+XbV1AaFy691iy+kGDv2Jvy0/eAh8Y1} PLUGIN_REMOTE_INSTALLING_HOST: ${PLUGIN_REMOTE_INSTALL_HOST:-0.0.0.0} PLUGIN_REMOTE_INSTALLING_PORT: ${PLUGIN_REMOTE_INSTALL_PORT:-5003} PLUGIN_WORKING_PATH: ${PLUGIN_WORKING_PATH:-/app/storage/cwd} FORCE_VERIFYING_SIGNATURE: ${FORCE_VERIFYING_SIGNATURE:-true} ports: - "${EXPOSE_PLUGIN_DEBUGGING_PORT:-5003}:${PLUGIN_DEBUGGING_PORT:-5003}" volumes: - ./volumes/plugin_daemon:/app/storage # ssrf_proxy server # for more information, please refer to # https://docs.dify.ai/learn-more/faq/install-faq#id-18.-why-is-ssrf_proxy-needed ssrf_proxy: image: ubuntu/squid:latest restart: always volumes: - ./ssrf_proxy/squid.conf.template:/etc/squid/squid.conf.template - ./ssrf_proxy/docker-entrypoint.sh:/docker-entrypoint-mount.sh entrypoint: [ 'sh', '-c', "cp /docker-entrypoint-mount.sh /docker-entrypoint.sh && sed -i 's/\r$$//' /docker-entrypoint.sh && chmod +x /docker-entrypoint.sh && /docker-entrypoint.sh" ] environment: # pls clearly modify the squid env vars to fit your network environment. HTTP_PORT: ${SSRF_HTTP_PORT:-3128} COREDUMP_DIR: ${SSRF_COREDUMP_DIR:-/var/spool/squid} REVERSE_PROXY_PORT: ${SSRF_REVERSE_PROXY_PORT:-8194} SANDBOX_HOST: ${SSRF_SANDBOX_HOST:-sandbox} SANDBOX_PORT: ${SANDBOX_PORT:-8194} networks: - ssrf_proxy_network - default ``` **Description of behavior** When I tried to upload a new document a second time, I received an Operational Error from the psycopg2 library. The error message was `FATAL: remaining connection slots are reserved for roles with the SUPERUSER attribute. Background on this error: {link to additional documentation}`. The additional documentation link pointed to this page: https://docs.sqlalchemy.org/en/20/errors.html#error-e3q8 Upon further investigation, when debugging this and checking active connections, the database showed several long-running queries under "ROLLBACK" and "COMMIT" that were hogging up the allocated connections. Although I'm not sure of the root cause, this may be related to the change regarding the `dify-plugin-daemon`. I'm not sure if this is required in 0.15.3 but it did get errors when spinning up the updated version. Some more guidance in the documentation about this `dify-plugin-daemon` would be helpful. ### ✔️ Expected Behavior Uploading and embedding a new document to just work like before in 0.14.1 ### ❌ Actual Behavior _No response_
yindo closed this issue 2026-02-21 18:25:12 -05:00
yindo commented 2026-02-21 18:25:13 -05:00
Author
Owner
Copy Link
Copy Source

@crazywoola commented on GitHub (Feb 17, 2025):

Try to increase this max_connections=${POSTGRES_MAX_CONNECTIONS:-100 to 2000.

@crazywoola commented on GitHub (Feb 17, 2025): Try to increase this `max_connections=${POSTGRES_MAX_CONNECTIONS:-100` to `2000`.
yindo commented 2026-02-21 18:25:13 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Feb 17, 2025):

@ytjhai Hello! I'm here to help you with any bugs, questions, or contributions. Let me know how I can assist you.

To address the "FATAL: remaining connection slots are reserved for roles with the SUPERUSER attribute" error in Dify version 0.15.3, you can try the following steps:

  1. Increase max_connections: Modify your PostgreSQL configuration to allow more concurrent connections. This can be done by adjusting the max_connections parameter in your PostgreSQL settings. If you're using Docker, you can set this in your docker-compose.middleware.yaml file as follows:

    command: >
  postgres -c 'max_connections=200'  # Increase this value as needed
           -c 'shared_buffers=${POSTGRES_SHARED_BUFFERS:-128MB}'
           -c 'work_mem=${POSTGRES_WORK_MEM:-4MB}'
           -c 'maintenance_work_mem=${POSTGRES_MAINTENANCE_WORK_MEM:-64MB}'
           -c 'effective_cache_size=${POSTGRES_EFFECTIVE_CACHE_SIZE:-4096MB}'

    Adjust the max_connections value based on your application's needs and the resources available on your server [1].

  2. Review dify-plugin-daemon Configuration: Ensure that the dify-plugin-daemon is correctly configured, as it interacts with the PostgreSQL database. Check the environment variables related to database connections, such as DB_HOST, DB_PORT, DB_USERNAME, DB_PASSWORD, and DB_DATABASE, to ensure they are set correctly [1].

  3. Optimize Connection Pooling: Consider adjusting the SQLALCHEMY_POOL_SIZE and SQLALCHEMY_POOL_RECYCLE settings to manage the database connection pool size and recycling time. The default SQLALCHEMY_POOL_SIZE is 30 connections, and SQLALCHEMY_POOL_RECYCLE is set to 3600 seconds. These can be adjusted to optimize performance and prevent connection slot exhaustion [2][3].

These steps should help mitigate the connection slot exhaustion issue you're experiencing.

To continue talking to Dosu, mention @dosu.

Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other

@dosubot[bot] commented on GitHub (Feb 17, 2025): <!-- Greeting --> @ytjhai Hello! I'm here to help you with any bugs, questions, or contributions. Let me know how I can assist you. <!-- Answer --> To address the "FATAL: remaining connection slots are reserved for roles with the SUPERUSER attribute" error in Dify version 0.15.3, you can try the following steps: 1. **Increase `max_connections`:** Modify your PostgreSQL configuration to allow more concurrent connections. This can be done by adjusting the `max_connections` parameter in your PostgreSQL settings. If you're using Docker, you can set this in your `docker-compose.middleware.yaml` file as follows: ```yaml command: > postgres -c 'max_connections=200' # Increase this value as needed -c 'shared_buffers=${POSTGRES_SHARED_BUFFERS:-128MB}' -c 'work_mem=${POSTGRES_WORK_MEM:-4MB}' -c 'maintenance_work_mem=${POSTGRES_MAINTENANCE_WORK_MEM:-64MB}' -c 'effective_cache_size=${POSTGRES_EFFECTIVE_CACHE_SIZE:-4096MB}' ``` Adjust the `max_connections` value based on your application's needs and the resources available on your server <sup>[[1]](https://github.com/langgenius/dify/blob/main/docker/docker-compose.middleware.yaml)</sup>. 2. **Review `dify-plugin-daemon` Configuration:** Ensure that the `dify-plugin-daemon` is correctly configured, as it interacts with the PostgreSQL database. Check the environment variables related to database connections, such as `DB_HOST`, `DB_PORT`, `DB_USERNAME`, `DB_PASSWORD`, and `DB_DATABASE`, to ensure they are set correctly <sup>[[1]](https://github.com/langgenius/dify/blob/main/docker/docker-compose.middleware.yaml)</sup>. 3. **Optimize Connection Pooling:** Consider adjusting the `SQLALCHEMY_POOL_SIZE` and `SQLALCHEMY_POOL_RECYCLE` settings to manage the database connection pool size and recycling time. The default `SQLALCHEMY_POOL_SIZE` is 30 connections, and `SQLALCHEMY_POOL_RECYCLE` is set to 3600 seconds. These can be adjusted to optimize performance and prevent connection slot exhaustion <sup>[[2]](https://github.com/langgenius/dify/blob/main/docker/.env.example)</sup><sup>[[3]](https://github.com/langgenius/dify-docs/blob/main/en/getting-started/install-self-hosted/environments.md)</sup>. These steps should help mitigate the connection slot exhaustion issue you're experiencing. <!-- Dosu Comment Footer --> *To continue talking to [Dosu](https://dosu.dev), mention @dosu.* --- <sup>Help Dosu learn! Give it feedback: [Great Response](https://app.dosu.dev/response-feedback/52480845-b67f-4c98-9c92-d152a20f154e?feedback_type=great_response) | [Irrelevant Answer](https://app.dosu.dev/response-feedback/52480845-b67f-4c98-9c92-d152a20f154e?feedback_type=irrelevant_answer) | [Incorrect Sources](https://app.dosu.dev/response-feedback/52480845-b67f-4c98-9c92-d152a20f154e?feedback_type=incorrect_sources) | [Too Verbose](https://app.dosu.dev/response-feedback/52480845-b67f-4c98-9c92-d152a20f154e?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/52480845-b67f-4c98-9c92-d152a20f154e?feedback_type=hallucination) | [Bug Report](https://app.dosu.dev/response-feedback/52480845-b67f-4c98-9c92-d152a20f154e?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/52480845-b67f-4c98-9c92-d152a20f154e?feedback_type=other)</sup>
yindo commented 2026-02-21 18:25:13 -05:00
Author
Owner
Copy Link
Copy Source

@ytjhai commented on GitHub (Feb 18, 2025):

Since this is a managed PostgreSQL DB, I cannot change the max connections, but lowering the SQLALCHEMY_POOL_SIZE per the bot's suggestion could be useful. I'll try and report back to see if it works here.

Edit: Lowering the pool size to 20 worked!

@ytjhai commented on GitHub (Feb 18, 2025): Since this is a managed PostgreSQL DB, I cannot change the max connections, but lowering the SQLALCHEMY_POOL_SIZE per the bot's suggestion could be useful. I'll try and report back to see if it works here. Edit: Lowering the pool size to 20 worked!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#8352
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?