Issue Station
Sign In
Tools hereToolbox

dify - ✅(Solved) Fix connections to postgresql exhausted [1 pull requests]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Error Message

  • The website shows "Internal server error" and almost nothing works anymore
  • API calls error out with 500

Fix Action

Fixed

PR fix notes

PR #35439: fix: increase maximum PostgreSQL connections to 200

Description (problem / solution / changelog)

with a default of 100, postgresql will run into sorry, too many clients already

Fixes #35438

Summary

Sets default of POSTGRES_MAX_CONNECTIONS to 200, because the default configuration of 100 will lead to problems with PostgreSQL: sorry, too many clients already

Checklist

  • This change requires a documentation update, included: Dify Document
  • [x ] I understand that this PR may be closed in case there was no previous discussion or issues. (This doesn't apply to typos!)
  • I've added a test for each change that was introduced, and I tried as much as possible to make a single atomic change.
  • I've updated the documentation accordingly.
  • I ran make lint && make type-check (backend) and cd web && pnpm exec vp staged (frontend) to appease the lint gods

Changed files

  • docker/.env.example (modified, +1/-1)
  • docker/docker-compose.yaml (modified, +1/-1)

Code Example

usename  | application_name | client_addr | state  | connections
----------+------------------+-------------+--------+-------------
 postgres |                  | 172.18.0.8  | idle   |          94
          |                  |             |        |           4
 postgres |                  | 172.18.0.6  | idle   |           4
 postgres | psql             |             | active |           1
 postgres |                  | 172.18.0.9  | idle   |           1
 postgres |                  |             |        |           1
RAW_BUFFERClick to expand / collapse

Self Checks

  • I have read the Contributing Guide and Language Policy.
  • 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, otherwise it will be closed.
  • 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
  • Please do not modify this template :) and fill in all the required fields.

Dify version

1.13.3

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

  1. update from 1.13.2 to 1.13.3
  2. open a few chats (we did this via API and the webchat)
  3. ask a few questions (in our case, 15 were enough)

✔️ Expected Behavior

Everything works as expected.

❌ Actual Behavior

  • The website shows "Internal server error" and almost nothing works anymore
  • API calls error out with 500
  • log shows db_postgres-1 | 2026-04-20 10:19:22.973 UTC [9713] FATAL: sorry, too many clients already

After this happened, we waited for almost an hour but the situation didn't get better.

We restarted docker and immediately connected to the database via psql to monitor the connections and hoping to be able to reproduce this. With every question in the chat, the amount of idle connections from the container docker-api-1 went up again in big steps, only dropping by 1 from time to time.

This is the current pretty stable state of connections:

 usename  | application_name | client_addr | state  | connections
----------+------------------+-------------+--------+-------------
 postgres |                  | 172.18.0.8  | idle   |          94
          |                  |             |        |           4
 postgres |                  | 172.18.0.6  | idle   |           4
 postgres | psql             |             | active |           1
 postgres |                  | 172.18.0.9  | idle   |           1
 postgres |                  |             |        |           1

We didn't change any settings regarding postgresql in the .env file

extent analysis

TL;DR

The issue is likely caused by a connection leak in the PostgreSQL database, and a workaround is to adjust the database connection pooling settings.

Guidance

  • Investigate the connection pooling settings in the docker-api-1 container to ensure that connections are being properly closed or returned to the pool after use.
  • Monitor the database connections using psql to identify any patterns or correlations between the number of connections and the chat activity.
  • Consider adjusting the PGPOOL settings or the connection timeout values in the .env file to mitigate the connection leak.
  • Review the PostgreSQL logs to see if there are any error messages or warnings related to connection limits or pooling.

Example

No specific code snippet can be provided without more information about the application code, but an example of how to adjust the connection pooling settings in a PostgreSQL configuration file might look like:

ALTER SYSTEM SET max_connections = 100;
ALTER SYSTEM SET idle_in_transaction_session_timeout = 30000;

However, this is highly dependent on the specific PostgreSQL version and configuration.

Notes

The issue seems to be related to the upgrade from version 1.13.2 to 1.13.3, but without more information about the changes made in the upgrade, it's difficult to provide a more specific solution. Additionally, the connection leak could be caused by a variety of factors, including application code, database configuration, or network issues.

Recommendation

Apply a workaround by adjusting the database connection pooling settings, as the root cause of the issue is likely related to the connection leak, and adjusting the pooling settings may help mitigate the problem.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#batch processing#GPU compatibility#latency issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING