Re: [HACKERS] Deadlock in XLogInsert at AIX - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: [HACKERS] Deadlock in XLogInsert at AIX
Date
Msg-id 5de6b64a-f842-9166-e41a-ed7b87a2729b@iki.fi
Whole thread Raw
In response to Re: [HACKERS] Deadlock in XLogInsert at AIX  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Responses Re: [HACKERS] Deadlock in XLogInsert at AIX
List pgsql-hackers
Oh, you were one step ahead of me, I didn't understand it on first read 
of your email. Need more coffee..

On 01/31/2017 05:03 PM, Konstantin Knizhnik wrote:
> I inspected code of pg_atomic_compare_exchange_u32_impl and didn't sync
> in prologue:
>
> (dbx) listi pg_atomic_compare_exchange_u32_impl> [no sync instruction]

> and if I compile this fuctions standalone, I get the following assembler
> code:
>
> .pg_atomic_compare_exchange_u32_impl:   # 0x0000000000000000 (H.4.NO_SYMBOL)
>          stdu       SP,-128(SP)
>          std        r3,176(SP)
>          std        r4,184(SP)
>          std        r5,192(SP)
>          ld         r0,192(SP)
>          stw        r0,192(SP)
>         sync
>          ld         r4,176(SP)
>          ld         r3,184(SP)
>          lwz        r0,192(SP)
>          extsw      r0,r0
>          lwa        r5,0(r3)> ...
>
> sync is here!

Ok, so, the 'sync' instruction gets lost somehow. That "standalone" 
assemly version looks slightly different in other ways too, you perhaps 
used different optimization levels, or it looks different when it's 
inlined into the caller. Not sure which version of the function gdb 
would show, when it's a "static inline" function. Would be good to check 
the disassembly of LWLockAttemptLock(), to see if the 'sync' is there.

Certainly seems like a compiler bug, though.

- Heikki




pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: [HACKERS] CONNECTION LIMIT and Parallel Query don't play welltogether
Next
From: Fabien COELHO
Date:
Subject: Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless)