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

  1. Fix pg_atomic_u64 initialization.

  2. Fix shm_toc.c to always return buffer-aligned memory.

  3. Use atomic ops to hand out pages to scan in parallel scan.

  4. Improve 64bit atomics support.