On Mon, Nov 14, 2022 at 9:41 AM Robert Haas <robertmh...@gmail.com> wrote:
> On Mon, Nov 14, 2022 at 11:35 AM Amit Singh <amitksingh.mum...@gmail.com> > wrote: > > Making the information available in pg_stat_activity makes it a lot > easier to identify the pid which has caused the subtran overflow. Debugging > through the app code can be an endless exercise and logging every statement > in postgresql logs is not practical either. If the overhead of fetching the > information isn't too big, I think we should consider the > subtransaction_count and is_overflowed field as potential candidates for > the enhancement of pg_stat_activity. > > The overhead of fetching the information is not large, but Justin is > concerned about the effect on the display width. I feel that's kind of > a lost cause because it's so wide already anyway, but I don't see a > reason why we need *two* new columns. Can't we get by with just one? > It could be overflowed true/false, or it could be the number of > subtransaction XIDs but with NULL instead if overflowed. > > Do you have a view on this point? > > NULL when overflowed seems like the opposite of the desired effect, calling attention to the exceptional status. Make it a text column and write "overflow" or "###" as appropriate. Anyone using the column is going to end up wanting to special-case overflow anyway and number-to-text conversion aside from overflow is simple enough if a number, and not just a display label, is needed. David J.
