Re: WIP: WAL prefetch (another approach) - Mailing list pgsql-hackers

From Andres Freund
Subject Re: WIP: WAL prefetch (another approach)
Date
Msg-id 20201230035736.qmyrtrpeewqbidfi@alap3.anarazel.de
Whole thread Raw
In response to Re: WIP: WAL prefetch (another approach)  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
Hi,

On 2020-12-24 16:06:38 +1300, Thomas Munro wrote:
> From 85187ee6a1dd4c68ba70cfbce002a8fa66c99925 Mon Sep 17 00:00:00 2001
> From: Thomas Munro <thomas.munro@gmail.com>
> Date: Sat, 28 Mar 2020 11:42:59 +1300
> Subject: [PATCH v15 1/6] Add pg_atomic_unlocked_add_fetch_XXX().
> 
> Add a variant of pg_atomic_add_fetch_XXX with no barrier semantics, for
> cases where you only want to avoid the possibility that a concurrent
> pg_atomic_read_XXX() sees a torn/partial value.  On modern
> architectures, this is simply value++, but there is a fallback to
> spinlock emulation.

Wouldn't it be sufficient to implement this as one function implemented as
    pg_atomic_write_u32(val, pg_atomic_read_u32(val) + 1)
then we'd not need any ifdefs?



> + * pg_atomic_unlocked_add_fetch_u32 - atomically add to variable

It's really not adding "atomically"...


> + * Like pg_atomic_unlocked_write_u32, guarantees only that partial values
> + * cannot be observed.

Maybe add a note saying that that in particularly means that
modifications could be lost when used concurrently?


Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: Parallel Inserts in CREATE TABLE AS
Next
From: Andres Freund
Date:
Subject: Re: Cache relation sizes?