From: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Dilip Kumar <dilipbalaut(at)gmail(dot)com>, James Sewell <james(dot)sewell(at)jirotech(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Max connections reached without max connections reached |
Date: | 2021-12-03 16:31:08 |
Message-ID: | 20211203163108.bfn4td7ruruh3bvp@localhost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> On Fri, Dec 03, 2021 at 10:32:03AM -0500, Tom Lane wrote:
> Dilip Kumar <dilipbalaut(at)gmail(dot)com> writes:
> > On Thu, Dec 2, 2021 at 9:35 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> >> I think there is no such view or anything which tells about which
> >> backend or transaction has more than 64 sub transaction. But if we
> >> are ready to modify the code then we can LOG that information in
> >> GetNewTransactionId(), when first time we are marking it overflown.
>
> > I have prepared a small patch to log this information.
>
> Putting an elog call into GetNewTransactionId seems like a completely
> horrid idea from a performance standpoint. Especially if you put it
> inside the XidGenLock hold, where it can block the entire system not just
> the one process. But even without that, this seems like a performance
> penalty with basically no real-world benefit. People who have issues
> like this are not going to want to trawl the postmaster log for such
> messages.
Maybe it's worth a trace point then, to allow collect such info sort of
on demand?
From | Date | Subject | |
---|---|---|---|
Next Message | Sebastien Flaesch | 2021-12-03 16:45:58 | Re: SUM() of INTERVAL type produces INTERVAL with no precision |
Previous Message | Adrian Klaver | 2021-12-03 16:30:08 | Re: SUM() of INTERVAL type produces INTERVAL with no precision |