On Fri, Apr 30, 2021 at 7:12 AM Thomas Munro <thomas.munro@gmail.com> wrote:
> But do you have lots of short overlapping transactions so that there
> is never a moment where there are zero transactions running?
Yeah, that almost certainly explains it.
Thanks very much for the explanation about the summarized locks.
> The number of SERIALIZABLEXACT objects is (max_connections +
> max_prepared_transactions) * 10. So, you could try increasing
> max_connections (without increasing the actual number of connections)
> to see if you can get to a point where you don't see these invalid
> virtual xids, and then maybe it'll be able to clean up locks more
> aggressively.
Aha! I hadn't considered that some parameter besides
max_pred_locks_per_transaction would come into play. I'll give this a
shot.
Thanks,
Mike