Re: WIP: WAL prefetch (another approach)
От | Andres Freund |
---|---|
Тема | Re: WIP: WAL prefetch (another approach) |
Дата | |
Msg-id | 20201230035736.qmyrtrpeewqbidfi@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: WIP: WAL prefetch (another approach) (Thomas Munro <thomas.munro@gmail.com>) |
Список | 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 по дате отправления: