Hi experts,
we have a Postgresql v14.8 database, almost thousands of backends hang
on MultiXactOffsetSLRU at the same time, all of these sessions running same
query "SELECT ", from OS and postgresql slow log, we found all of these
query on "BIND" stage.
LOG: duration: 36631.688 ms bind S
Hi,
I encountered this in a project we migrated to PostgreSQL
before, and unfortunately, it’s a situation that completely degrades
performance. We identified the cause as savepoints being used excessively
and without control. Once they reduced the number of savepoints, the issue
wa
On 2024-Sep-10, James Pang wrote:
> Hi experts,
> we have a Postgresql v14.8 database, almost thousands of backends hang
> on MultiXactOffsetSLRU at the same time, all of these sessions running same
> query "SELECT ", from OS and postgresql slow log, we found all of these
> query on "BIND"
On 2024-Sep-10, Amine Tengilimoglu wrote:
> Hi,
>
>I encountered this in a project we migrated to PostgreSQL
> before, and unfortunately, it’s a situation that completely degrades
> performance. We identified the cause as savepoints being used excessively
> and without control. O
There is no foreign keys, but there is one session who did transactions
to tables with savepoints, one savepoints/per sql in same transaction. But
sessions with query "SELECT “ do not use savepoints , just with a lot of
sessions running same query and hang on MultiXact suddenly. even only one
I hadn't found a satisfactory explanation about the top limit
related to SLRU, so this document will be useful. It's a nice development
that the relevant limit has been increased in pg17; I hope I don't
encounter a situation where this limit is exceeded in large systems.
Kind regard
On 2024-Sep-10, James Pang wrote:
> There is no foreign keys, but there is one session who did transactions
> to tables with savepoints, one savepoints/per sql in same transaction. But
> sessions with query "SELECT “ do not use savepoints , just with a lot of
> sessions running same query and
