On Fri, Jul 21, 2023 at 11:29 AM Michael Paquier <mich...@paquier.xyz> wrote: > > + /* Reading atomically avoids getting a torn value */ > + value = pg_atomic_read_u64(valptr); > > Should this specify that this is specifically important for platforms > where reading a uint64 could lead to a torn value read, if you apply > this term in this context? Sounding picky, I would make that a bit > longer, say something like that: > "Reading this value atomically is safe even on platforms where uint64 > cannot be read without observing a torn value." > > Only xlogprefetcher.c uses the term "torn" for a value by the way, but > for a write.
Done.
> 0001 looks OK-ish seen from here. Thoughts?
Yes, it looks safe to me too. FWIW, 0001 essentially implements what
an existing TODO comment introduced by commit 008608b9d5106 says:
/*
* Read value using the lwlock's wait list lock, as we can't generally
* rely on atomic 64 bit reads/stores. TODO: On platforms with a way to
* do atomic 64 bit reads/writes the spinlock should be optimized away.
*/
I'm attaching v10 patch set here - 0001 has modified the comment as
above, no other changes in patch set.
--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
v10-0001-Optimize-WAL-insertion-lock-acquisition-and-rele.patch
Description: Binary data
v10-0002-Improve-commets-in-and-around-LWLockWaitForVar-c.patch
Description: Binary data
v10-0003-Have-a-quick-exit-for-LWLockUpdateVar-when-there.patch
Description: Binary data
