On Mon, Jan 4, 2016 at 2:28 PM, Andres Freund <andres@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,