On Wed, Nov 23, 2022 at 2:10 AM Andres Freund <and...@anarazel.de> wrote: > > On 2022-11-21 17:06:56 +0900, Masahiko Sawada wrote: > > Sure. I've attached the v10 patches. 0004 is the pure refactoring > > patch and 0005 patch introduces the pointer tagging. > > This failed on cfbot, with som many crashes that the VM ran out of disk for > core dumps. During testing with 32bit, so there's probably something broken > around that. > > https://cirrus-ci.com/task/4635135954386944 > > A failure is e.g. at: > https://api.cirrus-ci.com/v1/artifact/task/4635135954386944/testrun/build-32/testrun/adminpack/regress/log/initdb.log > > performing post-bootstrap initialization ... > ../src/backend/lib/radixtree.c:1696:21: runtime error: member access within > misaligned address 0x590faf74 for type 'struct radix_tree_control', which > requires 8 byte alignment > 0x590faf74: note: pointer points here > 90 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 > ^
radix_tree_control struct has two pg_atomic_uint64 variables, and the assertion check in pg_atomic_init_u64() failed: static inline void pg_atomic_init_u64(volatile pg_atomic_uint64 *ptr, uint64 val) { /* * Can't necessarily enforce alignment - and don't need it - when using * the spinlock based fallback implementation. Therefore only assert when * not using it. */ #ifndef PG_HAVE_ATOMIC_U64_SIMULATION AssertPointerAlignment(ptr, 8); #endif pg_atomic_init_u64_impl(ptr, val); } I've investigated this issue and have a question about using atomic variables on palloc'ed memory. In non-parallel vacuum cases, radix_tree_control is allocated via aset.c. IIUC in 32-bit machines, the memory allocated by aset.c is 4-bytes aligned so these atomic variables are not always 8-bytes aligned. Is there any way to enforce 8-bytes aligned memory allocations in 32-bit machines? Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com