Hi,
Got this issue again.
Settings on the platform (PG 9.6.11):
max_pred_locks_per_transaction = 3000
max_connections = 800
Despite the fact that documentation says:
> with the exception of fast-path locks, each lock manager will deliver a consistent set of results
I've noticed the following:
1. pg_locks showed 2 million SIReadLocks for the pid that has been in the "idle" state for a dozen of seconds already.
2. pg_locks showed count of 5 million SIReadLock granted although I expected a limit of 2.4 million SIReadLocks with settings provided above.
And still no any signs of serializable transactions that could live for a 1 billion xids.
--
Pavel Suderevsky
E: psuderevsky(at)gmail(dot)com
On Sun, Apr 7, 2019 at 2:31 AM Pavel Suderevsky <psuderevsky@gmail.com> wrote:
> Probably if you advise me what could cause "pg_serial": apparent wraparound messages I would have more chances to handle all the performance issues.
Did you see that warning at some point before the later error?
Thomas,
Thank you for your reply!
No, there have never been such warnings.
I wonder if this condition required you to have a serializable
transaction running (or prepared) while you consume 2^30 AKA ~1
billion xids. I think it is unreachable in v11+ because commit
e5eb4fa8 allowed for more SLRU pages to avoid this artificially early
wrap.
Do I understand right that this is about Virtual txids? Have no idea how even a something close to a billion of transaction ids could be consumed on this system.
--
Pavel Suderevsky