From: Tom Lane <tgl@sss.pgh.pa.us>
To: Joe Conway <mail@joeconway.com>
cc: Jeff Janes <jeff.janes@gmail.com>, ravi.s.agrawal23@gmail.com,
        pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18141: sorry,
 too many clients error occurring very frequently
In-reply-to: <b3d50783-fc7d-0239-5343-6bfe7f654334@joeconway.com>
References: <18141-198c521115e07b7c@postgresql.org>
 <CAMkU=1zXTm-zAq2jRoscmqDmDGPjRy_18BhOn_-Jb0TuGbHHbg@mail.gmail.com>
 <b3d50783-fc7d-0239-5343-6bfe7f654334@joeconway.com>
Comments: In-reply-to Joe Conway <mail@joeconway.com>
	message dated "Sun, 01 Oct 2023 10:34:15 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1848410.1696183788.1@sss.pgh.pa.us>
Date: Sun, 01 Oct 2023 14:09:48 -0400
Message-ID: <1848411.1696183788@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1848411.1696183788%40sss.pgh.pa.us>
Precedence: bulk

Joe Conway <mail@joeconway.com> writes:
> 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.

Hmm.  My first instinct is to wonder about changes in plan selection.
How complex were the troublesome queries?

			regards, tom lane