Re: Max connections reached without max connections reached

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Cc: 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 15:32:03
Message-ID: 2293661.1638545523@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Laurenz Albe 2021-12-03 16:00:53 Re: libpq: Which functions may hang due to network issues?
Previous Message Tom Lane 2021-12-03 15:15:36 Re: SUM() of INTERVAL type produces INTERVAL with no precision