Hi, On 2018-06-21 00:25:03 +1200, David Rowley wrote: > On 19 June 2018 at 17:43, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > > The problem is that StandbyReleaseLocks() does a linear search of all > > known AccessExclusiveLocks when a transaction ends. Luckily, since > > v10 (commit 9b013dc2) that is skipped for transactions that haven't > > taken any AELs and aren't using 2PC, but that doesn't help all users. > > Good to see this getting fixed. My original patch [1] to fix this was > more along the lines of yours
>From that discussion I don't really understand why that wasn't pursued further. The revision committed, clearly was just continuing to use the wrong datastructure, and had obvious issues with complexity, just in a somewhat narrower situation? > only I partitioned the List in an array indexed by the xid mod size of > array. I had done this as I thought it would be faster than a hash > table and would likely see the locks spread evenly over the table. > IIRC Andres complained and said I should use a hashtable, which I see > you've done. It's hard to believe the hashtable is a meaningful bottleneck here. The primary also uses a hashtable, except it's partitioned & shared, and thus protected by locks. Also much larger. So it's hard to believe that we'd need a custom built datastructure to speedup replay... Greetings, Andres Freund
