Hi, On 2021-04-13 23:04:50 -0400, Tom Lane wrote: > Andres Freund <andres@xxxxxxxxxxx> 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
