Hi,
On 2018-06-21 00:25:03 +1200, David Rowley wrote:
> On 19 June 2018 at 17:43, Thomas Munro <thomas.munro@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
