| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Joe Conway <mail(at)joeconway(dot)com> |
| Cc: | 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 18:09:48 |
| Message-ID: | 1848411.1696183788@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Joe Conway <mail(at)joeconway(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joe Conway | 2023-10-01 18:27:05 | Re: BUG #18141: sorry, too many clients error occurring very frequently |
| Previous Message | Jorge Soro Domenech | 2023-10-01 16:39:57 | Re: Help pg_restore version |