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/>
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 |