Re: Atomics for heap_parallelscan_nextpage()
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: pgsql-hackers@postgresql.org,Robert Haas <robertmhaas@gmail.com>,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>
Date: 2017-08-16T17:56:20Z
Lists: pgsql-hackers
On August 16, 2017 10:47:23 AM PDT, Robert Haas <robertmhaas@gmail.com> wrote: >On Wed, Aug 16, 2017 at 1:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I was wondering why the shm_toc code was using BUFFERALIGN and not >> MAXALIGN, and I now suspect that the answer is "it's an entirely >> undocumented kluge to make the atomics code not crash on 32-bit >> machines, so long as nobody puts a pg_atomic_uint64 anywhere except >> in a shm_toc". > >Well, shm_toc considerably predates 64-bit atomics, so I think the >causality cannot run in that direction. shm_toc.c first appeared in >the tree in January of 2014. src/include/port/atomics didn't show up >until September of that year, and 64-bit atomics weren't actually >usable in practice until e8fdbd58fe564a29977f4331cd26f9697d76fc40 in >April of 2017. Well, not for core code. I certainly know about production code using it, because crusty platforms are considered irrelevant... Independent of that, a comment explaining what the BUFFERALIGN is intending would be good. Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
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