Re: LogwrtResult contended spinlock
От | Alvaro Herrera |
---|---|
Тема | Re: LogwrtResult contended spinlock |
Дата | |
Msg-id | 202407010910.ktykqkc52ffb@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: LogwrtResult contended spinlock (Alexander Lakhin <exclusion@gmail.com>) |
Ответы |
Re: LogwrtResult contended spinlock
Re: LogwrtResult contended spinlock |
Список | pgsql-hackers |
Hello, On 2024-Jun-29, Alexander Lakhin wrote: > It doesn't, but the following works for me: > static inline uint64 > pg_atomic_monotonic_advance_u64(volatile pg_atomic_uint64 *ptr, uint64 target_) > { > - uint64 currval; > + pg_attribute_aligned(8) uint64 currval; > > because the failed assertion is: > #ifndef PG_HAVE_ATOMIC_U64_SIMULATION > AssertPointerAlignment(&currval, 8); > #endif Hah, thank you. In the meantime I noticed that pg_attribute_aligned() is not supported in every platform/compiler, so for safety sake I think it's better to go with what we do for PGAlignedBlock: use a union with a double member. That should be 8-byte aligned on x86 as well, unless I misunderstand. BTW if things works after this fix, I suggest you get a buildfarm member running with this configuration. Otherwise it's quite likely that we'll break it again. Or we could just decide we don't care about this particular platform ... but AFAICS the buildfarm does have other 32-bit animals running. [ looks at buildfarm ] Oh! while looking at Adder's config, I noticed this line: Checking for alignment of "double" : 4 So, I do misunderstand doubles. So my patch is not going to work. There seems to be nothing that has alignment 8 there, so I guess we're back to using pg_attribute_aligned() and abort the compile if that doesn't exist. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "La gente vulgar sólo piensa en pasar el tiempo; el que tiene talento, en aprovecharlo"
Вложения
В списке pgsql-hackers по дате отправления: