On Tue, Nov 15, 2022 at 2:47 AM Andres Freund <andres@anarazel.de> wrote:
>
> First, it's not good to have a cliff that you can't see coming - presumbly
> you'd want to warn *before* you regularly reach PGPROC_MAX_CACHED_SUBXIDS
> subxids, rather when the shit has hit the fan already.
I agree with the point that it is good to have a way to know that the
problem is about to happen. So for that reason, we should show the
subtransaction count. With showing count user can exactly know if
there are some sessions that could create problems in near future and
may take some action before the problem actually happens.
> IMO the number matters a lot when analyzing why this is happening / how to
> react. A session occasionally reaching 65 subxids might be tolerable and not
> necessarily indicative of a bug. But 100k subxids is something that one just
> can't accept.
Actually, we will see the problem as soon as it has crossed 64 because
after that for any visibility checking we need to check the SLRU. So
I feel both count and overflow are important. Count to know that we
are heading towards overflow and overflow to know that it has already
happened.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com