|From:||Heikki Linnakangas <hlinnaka(at)iki(dot)fi>|
|To:||Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>|
|Subject:||Re: Atomics for heap_parallelscan_nextpage()|
|Views:||Raw Message | Whole Thread | Download mbox|
On 08/16/2017 08:10 PM, Andres Freund wrote:
>> Afaict shm_create/shm_toc_allocate don't actually guarantee that the end
>> of the toc's memory is suitably aligned. But I didn't yet have any
>> coffee, so ...
> Robert, I'm not quite sure what the intended behaviour of shm_toc is wrt
> alignment. I see that individual chunks are BUFFERALIGNed (both during
> estimation, and allocation). But I don't see how the size of the entire
> toc is aligned, which seems a requirement, given we allocate from the
> Seems like we'd just have to add alignment of the total size to
Yeah, that's the gist of it.
The attached patch seems to fix this. I'm not too familiar with this DSM
stuff, but this seems right to me. Unless someone has a better idea
soon, I'll commit this to make the buildfarm happy.
|Next Message||Robert Haas||2017-08-16 17:20:36||Re: Garbled comment in postgresGetForeignJoinPaths|
|Previous Message||Robert Haas||2017-08-16 17:16:50||Re: Hash Functions|