Re: BUG #18141: sorry, too many clients error occurring very frequently

From: Joe Conway <mail(at)joeconway(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, ravi(dot)s(dot)agrawal23(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18141: sorry, too many clients error occurring very frequently
Date: 2023-10-01 14:34:15
Message-ID: b3d50783-fc7d-0239-5343-6bfe7f654334@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 9/30/23 14:04, Jeff Janes wrote:
> On Fri, Sep 29, 2023 at 7:55 PM PG Bug reporting form
> <noreply(at)postgresql(dot)org <mailto:noreply(at)postgresql(dot)org>> wrote:
>
> The following bug has been logged on the website:
>
> Bug reference:      18141
> Logged by:          Ravi Agrawal
> Email address: ravi(dot)s(dot)agrawal23(at)gmail(dot)com
> <mailto:ravi(dot)s(dot)agrawal23(at)gmail(dot)com>
> PostgreSQL version: 13.11
> Operating system:   RHEL
> Description:
>
> Hi Team,
>
> We have updated PostgresSQL from version 13.4 to 13.11 and observing
> 'sorry,
> too many clients' error very frequently.
> Connection count is shooting up on performing basic operations  and
> crossing
> the max_connections value. This has not been observed previously on
> Postgres
> v13.4
> We need to understand if this issue is caused due to the change in
> version.
> Is there any history of known incidents facing this issue with the
> specific
> version of PostgreSQL.
>
>
> I think it is unlikely to be a bug.  How did you do the upgrade?  Just
> install the new binaries, then restart the server?

Maybe, maybe not. I have seen two other cases that are similar. One was
an upgrade from 12.8 to 12.12 and the other an upgrade from 13.4 to 13.8.

I checked and 12.8 was stamped is the same date as 13.4, and 12.12 the
same day as 13.8.

In both cases queries against pg_stat_statements suddenly started taking
more memory leading to spillage to pg_temp and a step degradation in
overall performance. In at least one of those cases the
solution/workaround was to increase work_mem. In the other I think
pg_stat_statements was disabled.

Myself and at least one other hacker looked at the pg_stat_statements
specific changes in that time interval and saw no smoking gun.

But it is possible that something else backpatched to both branches
between Aug 09, 2021 and Aug 8, 2022 has caused a more general
performance regression which we have yet to track down.

At least based on this sample of two (now maybe 3?) folks with similar
symptoms.

--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Jorge Soro Domenech 2023-10-01 15:28:40 Re: Help pg_restore version
Previous Message Euler Taveira 2023-10-01 13:29:45 Re: Help pg_restore version