From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
---|---|
To: | James Sewell <james(dot)sewell(at)jirotech(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Max connections reached without max connections reached |
Date: | 2021-12-03 09:01:23 |
Message-ID: | CAFiTN-v6FrBe9FTtZa-CT0r7UViWEz0_5ziU7k6cOHPhFsyMvA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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.
> if (nxids < PGPROC_MAX_CACHED_SUBXIDS)
> {
> MyProc->subxids.xids[nxids] = xid;
> pg_write_barrier();
> MyProc->subxidStatus.count = substat->count = nxids + 1;
> }
> else
> {
> MyProc->subxidStatus.overflowed = substat->overflowed = true;
> <-- we can log or put breakpoint here and identify which statement is
> creating oeverflow-->
> }
>
> IMHO, it is good to LOG such information if we are not already logging
> this anywhere.
>
I have prepared a small patch to log this information.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
0001-LOG-subxid-cache-overflow-message.patch | text/x-patch | 935 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Frey | 2021-12-03 10:37:56 | libpq: Which functions may hang due to network issues? |
Previous Message | Yi Sun | 2021-12-03 07:41:51 | Re: ssl_crl_file Certificate Revocation List doesn't work for postgresql 11 |