Re: [HACKERS] Atomics for heap_parallelscan_nextpage()
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] Atomics for heap_parallelscan_nextpage() |
Дата | |
Msg-id | 20170816190245.uqv6kswf3uud24gp@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] Atomics for heap_parallelscan_nextpage() (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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
В списке pgsql-hackers по дате отправления: