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.
>
> On Sun, Apr 7, 2019 at 2:31 AM Pavel Suderevsky
> 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,
Th
On Tue, Apr 9, 2019 at 12:14 PM Thomas Munro wrote:
> It's more doable here than elsewhere because the data on disk isn't
> persistent across server restart, let alone pg_upgrade. Let's see...
> each segment file is 256kb and we need to be able to address 2^64 *
> sizeof(SerCommitSequenceNumber),
On Sun, Apr 7, 2019 at 2:31 AM Pavel Suderevsky 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.
9.6 has this code:
/*
* Give a warning if we're about to run out of SL
Guys, still need your help.
Previous night:
*2019-04-05 00:35:04 UTC LOG: could not truncate directory "pg_serial":
apparent wraparound*
*2019-04-05 00:40:04 UTC LOG: could not truncate directory "pg_serial":
apparent wraparound*
(2 checkpoints)
It turned that I have some problem with perform
