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 вт, 9 апр. 2019 г. в 16:00, Pavel Suderevsky <psuderev...@gmail.com>: > On Sun, Apr 7, 2019 at 2:31 AM Pavel Suderevsky <psuderev...@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 > E: psuderev...@gmail.com >
