Re: Re: [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.
В списке pgsql-hackers по дате отправления:
| От | Andres Freund |
|---|---|
| Тема | Re: Re: [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner. |
| Дата | |
| Msg-id | 20160412040335.7melgsixigrhr656@alap3.anarazel.de обсуждение исходный текст |
| Ответ на | Re: Re: [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner. (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
On 2016-04-11 23:59:21 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > Will fix (both initialization and use of pg_atomic_fetch_or_u32), and > > expand the documentation on why only atomic read/write are supposed to > > be used. > > FWIW, I'd vote against adding a SpinLockInit there. Well, it'd not be a SpinLockInit, but a pg_atomic_init_u32(), but ... > What it would mostly > do is prevent noticing future mistakes of the same ilk. It would be > better no doubt if we didn't have to rely on a nearly-dead platform > to detect this; but having such detection of a performance bug is better > than having no detection. Ok, works for me as well. I guess it'd be useful to add a "modern" animal that disables spinlocks & atomics... - Andres
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера