Horton

Re: global / super barriers (for checksums)

Magnus Hagander <magnus@hagander.net>

View thread View on postgr.es
From: Magnus Hagander <magnus@hagander.net>
To: Andres Freund <andres@anarazel.de>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>, Daniel Gustafsson <daniel@yesql.se>
Date: 2018-12-27T13:42:15Z
Lists: pgsql-hackers 
On Thu, Dec 27, 2018 at 2:22 PM Andres Freund <andres@anarazel.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/>

Commits

  1. Online enabling and disabling of data checksums

  2. Extend the ProcSignal mechanism to support barriers.

  3. Partially deduplicate interrupt handling for background processes.

  4. Use PostgresSigHupHandler in more places.

  5. Move interrupt-handling code into subroutines.

  6. Use procsignal_sigusr1_handler for auxiliary processes.