Re: global / super barriers (for checksums)

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Daniel Gustafsson <daniel(at)yesql(dot)se>
Subject: Re: global / super barriers (for checksums)
Date: 2018-12-27 13:42:15
Message-ID: CABUevEzWqhmdi24Yx8u3_Cm1nk+uvF=_zbsp5bURzDsEDByMhA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Dec 27, 2018 at 2:22 PM Andres Freund <andres(at)anarazel(dot)de> wrote:

> Hi,
>
> On 2018-12-27 13:54:34 +0100, Magnus Hagander wrote:
> > Finally getting around to playing with this one and it unfortunately
> > doesn't apply anymore (0003).
> >
> > I think it's just a matter of adding those two rows though, right? That
> is,
> > it's not an actual conflict it's just something else added in the same
> > place?
>
> What do you mean with "rows" here? I see a bunch of trivial conflicts
> due to changes in atomics initialization but nothing else? And yes, I'd
> not expect any meaningful conflicts.
>
>
Sorry, lack of caffeine. The conflict I saw was:

/* Initialize lockGroupMembers list. */
dlist_init(&procs[i].lockGroupMembers);
+
+ pg_atomic_init_u32(&procs[i].barrierFlags, 0);
+ pg_atomic_init_u64(&procs[i].barrierGen, PG_UINT64_MAX);
}

So yes, I'm pretty sure we're talking about the same thing.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jonathan S. Katz 2018-12-27 14:38:24 Re: tickling the lesser contributor's withering ego
Previous Message Alvaro Herrera 2018-12-27 13:24:17 Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly