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
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
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
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
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"
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
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
