Обсуждение: Re: [HACKERS] [COMMITTERS] pgsql: Improve 64bit atomics support.
Andres Freund wrote: > Improve 64bit atomics support. > > When adding atomics back in b64d92f1a, I added 64bit support as > optional; there wasn't yet a direct user in sight. That turned out to > be a bit short-sighted, it'd already have been useful a number of times. Seems like this killed an arapaima: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=arapaima&dt=2017-04-07%2022%3A06%3A59 Program terminated with signal 6, Aborted. #0 0x00c6a402 in __kernel_vsyscall () #0 0x00c6a402 in __kernel_vsyscall () #1 0x00284b10 in raise () from /lib/libc.so.6 #2 0x00286421 in abort () from /lib/libc.so.6 #3 0x084d967e in ExceptionalCondition ( conditionName=0xe19dac "(((uintptr_t) ((uintptr_t)(ptr)) + ((8) - 1)) & ~((uintptr_t)((8) - 1))) != (uintptr_t)(ptr)", errorType=0xe19831 "UnalignedPointer", fileName=0xe19d88 "../../../src/include/port/atomics.h",lineNumber=428) at assert.c:54 #4 0x00e189b0 in pg_atomic_init_u64 () at ../../../src/include/port/atomics.h:428 #5 test_atomic_uint64 () at regress.c:1007 #6 0x00e1905d in test_atomic_ops (fcinfo=0x9362584) at regress.c:1097 #7 0x08273ab2 in ExecInterpExpr (state=0x9362510, econtext=0x93622e0, isnull=0xbfbc1a4b "") at execExprInterp.c:650 #8 0x082990a7 in ExecEvalExprSwitchContext (node=0x9362294) at ../../../src/include/executor/executor.h:289 #9 ExecProject (node=0x9362294) at ../../../src/include/executor/executor.h:323 #10 ExecResult (node=0x9362294) at nodeResult.c:132 #11 0x0827c6d5 in ExecProcNode (node=0x9362294) at execProcnode.c:416 #12 0x0827a08d in ExecutePlan (queryDesc=0x92daf38, direction=ForwardScanDirection, count=0, execute_once=1 '\001') at execMain.c:1651 #13 standard_ExecutorRun (queryDesc=0x92daf38, direction=ForwardScanDirection, count=0, execute_once=1 '\001') at execMain.c:360 #14 0x083cd8bb in PortalRunSelect (portal=0x92d78a8, forward=<value optimized out>, count=0, dest=0x9337728) at pquery.c:933 #15 0x083cef1e in PortalRun (portal=0x92d78a8, count=2147483647, isTopLevel=1 '\001', run_once=1 '\001', dest=0x9337728, altdest=0x9337728, completionTag=0xbfbc1c6a "") at pquery.c:774 #16 0x083cb38f in exec_simple_query ( query_string=0x93360b0 "SELECT test_atomic_ops();") at postgres.c:1105 #17 0x083cc640 in PostgresMain (argc=1, argv=0x92e4160, dbname=0x92e3fe0 "regression", username=0x92e3fc4 "postgres") at postgres.c:4075 #18 0x08349eaf in BackendStartup () at postmaster.c:4317 #19 ServerLoop () at postmaster.c:1729 #20 0x0834db50 in PostmasterMain (argc=8, argv=0x92b9968) at postmaster.c:1337 #21 0x082c01e2 in main (argc=8, argv=Cannot access memory at address 0x5aa5 ) at main.c:228 -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2017-04-07 19:55:21 -0300, Alvaro Herrera wrote: > Andres Freund wrote: > > Improve 64bit atomics support. > > > > When adding atomics back in b64d92f1a, I added 64bit support as > > optional; there wasn't yet a direct user in sight. That turned out to > > be a bit short-sighted, it'd already have been useful a number of times. > > Seems like this killed an arapaima: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=arapaima&dt=2017-04-07%2022%3A06%3A59 > > Program terminated with signal 6, Aborted. > #0 0x00c6a402 in __kernel_vsyscall () > #0 0x00c6a402 in __kernel_vsyscall () > #1 0x00284b10 in raise () from /lib/libc.so.6 > #2 0x00286421 in abort () from /lib/libc.so.6 > #3 0x084d967e in ExceptionalCondition ( > conditionName=0xe19dac "(((uintptr_t) ((uintptr_t)(ptr)) + ((8) - 1)) & ~((uintptr_t) ((8) - 1))) != (uintptr_t)(ptr)", > errorType=0xe19831 "UnalignedPointer", > fileName=0xe19d88 "../../../src/include/port/atomics.h", lineNumber=428) > at assert.c:54 > #4 0x00e189b0 in pg_atomic_init_u64 () > at ../../../src/include/port/atomics.h:428 Gah, that's fairly annoying :(. We can't trivially force alignment in the generic fallback case, because not all compilers support that. We don't really need it the fallback case, because things are protected by a lock - but that means we'll have to make a bunch of locks conditional :/ Greetings, Andres Freund
On 2017-04-07 16:36:09 -0700, Andres Freund wrote: > On 2017-04-07 19:55:21 -0300, Alvaro Herrera wrote: > > Andres Freund wrote: > > > Improve 64bit atomics support. > > > > > > When adding atomics back in b64d92f1a, I added 64bit support as > > > optional; there wasn't yet a direct user in sight. That turned out to > > > be a bit short-sighted, it'd already have been useful a number of times. > > > > Seems like this killed an arapaima: > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=arapaima&dt=2017-04-07%2022%3A06%3A59 > > > > Program terminated with signal 6, Aborted. > > #0 0x00c6a402 in __kernel_vsyscall () > > #0 0x00c6a402 in __kernel_vsyscall () > > #1 0x00284b10 in raise () from /lib/libc.so.6 > > #2 0x00286421 in abort () from /lib/libc.so.6 > > #3 0x084d967e in ExceptionalCondition ( > > conditionName=0xe19dac "(((uintptr_t) ((uintptr_t)(ptr)) + ((8) - 1)) & ~((uintptr_t) ((8) - 1))) != (uintptr_t)(ptr)", > > errorType=0xe19831 "UnalignedPointer", > > fileName=0xe19d88 "../../../src/include/port/atomics.h", lineNumber=428) > > at assert.c:54 > > #4 0x00e189b0 in pg_atomic_init_u64 () > > at ../../../src/include/port/atomics.h:428 > > Gah, that's fairly annoying :(. We can't trivially force alignment in > the generic fallback case, because not all compilers support that. We > don't really need it the fallback case, because things are protected by > a lock - but that means we'll have to make a bunch of locks conditional > :/ Pushed an attempt at fixing this along those lines, let's hope that works. - Andres