Re: LWLocks by LockManager slowing large DB

Hi,

On 2021-04-13 23:04:50 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2021-04-13 19:16:46 -0400, Tom Lane wrote:
> >> Like this? This passes check-world, modulo the one very-unsurprising
> >> regression test change. I've not tried to do any performance testing.
>
> > I wonder if there's a realistic chance it could create additional
> > deadlocks that don't exist right now?
>
> Not on user tables, because we'd always be holding at least as much
> of a lock on the parent table. However ...

I suspect that's not strictly *always* the case due to some corner cases
around a variable to a toast value in plpgsql surviving subtransactions
etc...

> The concerns that had come to my mind were more along the lines
> of things like pg_dump requiring a larger footprint in the shared
> lock table. We could alleviate that by increasing the default
> value of max_locks_per_transaction, perhaps.

Probably worth doing one of these releases independently - especially
with partitioning the current value strikes me as being on the too low
side.

Greetings,

Andres Freund