On Fri, Jan 15, 2016 at 11:23 AM, Mithun Cy <mithun...@enterprisedb.com> wrote:
> On Mon, Jan 4, 2016 at 2:28 PM, Andres Freund <and...@anarazel.de> wrote: > > > I think at the very least the cache should be protected by a separate > > lock, and that lock should be acquired with TryLock. I.e. the cache is > > updated opportunistically. I'd go for an lwlock in the first iteration. > > I tried to implement a simple patch which protect the cache. Of all the > backend which > compute the snapshot(when cache is invalid) only one of them will write to > cache. > This is done with one atomic compare and swap operation. > > After above fix memory corruption is not visible. But I see some more > failures at higher client sessions(128 it is easily reproducible). > > Don't you think we need to update the snapshot fields like count, subcount before saving it to shared memory? With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com