Re: pgsql: Fix race condition in snapshot caching when 2PC is used.

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

In response to

Responses

Browse pgsql-committers by date

  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.