Re: POC: Cache data in GetSnapshotData()

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: POC: Cache data in GetSnapshotData()
Date: 2016-01-15 09:27:53
Message-ID: CAA4eK1JOuZabO64+rK5Xuo4mP15D8WbCkDOpRMnqXOKe2WFJjw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jan 15, 2016 at 11:23 AM, Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com>
wrote:

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Artur Zakirov 2016-01-15 09:53:52 Re: Fuzzy substring searching with the pg_trgm extension
Previous Message Magnus Hagander 2016-01-15 09:25:03 Re: Comment typo in port/atomics/generic.h