From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pgsql: Fix race condition in snapshot caching when 2PC is used. |
Date: | 2020-08-18 23:55:50 |
Message-ID: | 1356510.1597794950@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2020-08-18 19:43:24 -0400, Tom Lane wrote:
>> Uh, is it really okay to modify that variable with only shared
>> ProcArrayLock?
> Uh, you're right. I assume it'll fix the buildfarm visible issue
> regardless, but we surely don't want to rely on that.
Yeah, having a failure show on the buildfarm would take an order of
magnitude (at least) tighter timing than what we're seeing now.
But I think it could possibly be a problem on big production iron.
> I'm inclined to just make ClearTransaction take an exclusive lock - the
> rest of the 2PC operations are so heavyweight that I can't imagine
> making a difference. When I tested the locking changes in
> ProcArrayAdd()/Remove() the more heavyweight locking wasn't at all
> visible.
I was wondering if it'd be sensible to convert that counter into an
atomic variable. That's not real clear, but worth thinking about.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2020-08-19 00:37:13 | Re: pgsql: Fix race condition in snapshot caching when 2PC is used. |
Previous Message | Andres Freund | 2020-08-18 23:51:52 | Re: pgsql: Fix race condition in snapshot caching when 2PC is used. |