Re: Atomics for heap_parallelscan_nextpage()
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, David Rowley <david.rowley@2ndquadrant.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Amit Khandekar <amitdkhan.pg@gmail.com>, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>, Robert Haas <robertmhaas@gmail.com>
Date: 2017-08-16T19:02:45Z
Lists: pgsql-hackers
On 2017-08-16 14:09:08 -0400, Tom Lane wrote: > >> I'm not sure that that's good enough, and I'm damn sure that it > >> shouldn't be undocumented. > > > 8 byte alignment would be good enough, so BUFFERALIGN ought to be > > sufficient. But it'd be nicer to have a separate more descriptive knob. > > What I meant by possibly not good enough is that pg_atomic_uint64 used > in other places isn't going to be very safe. Well, it's not used otherwise in core so far, leaving test code aside. It's correctly aligned if part of a aligned struct - the atomics code itself can't really do anything about aligning that struct itself isn't aligned. > We might be effectively all right as long as we have a coding rule that > pg_atomic_uint64 can only be placed in memory handed out by ShmemAlloc > or shm_toc_allocate, which both have bigger-than-MAXALIGN alignment > practices. But this needs to be documented. Well, one could argue the alignment checks in every function are that :). But yea, we probably should mention it more than that. Greetings, Andres Freund
Commits
-
Fix pg_atomic_u64 initialization.
- dcd052c8d20c 11.0 landed
-
Fix shm_toc.c to always return buffer-aligned memory.
- ac883ac453e9 11.0 landed
-
Use atomic ops to hand out pages to scan in parallel scan.
- 3cda10f41bfe 11.0 landed
-
Improve 64bit atomics support.
- e8fdbd58fe56 10.0 cited