Thread: 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