From: | Mike Beachy <mbeachy(at)gmail(dot)com> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: -1/0 virtualtransaction |
Date: | 2021-04-30 20:53:52 |
Message-ID: | CAEoC5=H6xCMytEPzXKiU2NGuD332TeWVmNhvCy9BGs4QpqgQJw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, Apr 30, 2021 at 7:12 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jian He | 2021-05-01 07:06:49 | database sorting algorithms. |
Previous Message | Bruce Momjian | 2021-04-30 19:32:54 | Re: pg_upgrade and wraparound |