We finally identified the cause, a pl/pgsql procedure proc1 (for 1…5000 loop call proc2()); proc2 (begin ..exception..end); at the same time, more than 200 sessions coming in milliseconds and do same query during the “call proc1 long running transaction”. The code change and cutdown the parallel sessions count doing same query at the same time help a lot.
Thanks all. James From: Nikolay Samokhvalov <samokhva...@gmail.com> Sent: Friday, February 2, 2024 6:04 PM To: Laurenz Albe <laurenz.a...@cybertec.at>; pgsql-performance@lists.postgresql.org Subject: Re: huge SubtransSLRU and SubtransBuffer wait_event On Thu, Feb 1, 2024 at 04:42 Laurenz Albe <laurenz.a...@cybertec.at<mailto:laurenz.a...@cybertec.at>> wrote: Today, the only feasible solution is not to create more than 64 subtransactions (savepoints or PL/pgSQL EXCEPTION clauses) per transaction. Sometimes, a single subtransaction is enough to experience a bad SubtransSLRU spike: https://postgres.ai/blog/20210831-postgresql-subtransactions-considered-harmful#problem-4-subtrans-slru-overflow I think 64+ nesting level is quite rare, but this kind of problem that hits you when you have high XID growth (lots of writes) + long-running transaction is quite easy to bump into. Or this case involving MultiXactIDs: https://buttondown.email/nelhage/archive/notes-on-some-postgresql-implementation-details/ Nik
