Re: Intermediate report for AIX 5L port - Mailing list pgsql-hackers

Tom, Have you fixed the case on AIX 5L?  I still see hunging backends
with pgbench -c 64. Maybe AIX 5L (more precisely xlc) needs additional
fixed? If so, I'm wondering why see no improvements even with gcc.
--
Tatsuo Ishii

(dbx) where
semop(??, ??, ??) at 0xd02be73c
IpcSemaphoreLock() at 0x100091d0
LWLockAcquire() at 0x10019df4
ReleaseBuffer() at 0x100205a4
CatalogIndexFetchTuple() at 0x1005a31c
AttributeRelidNumIndexScan() at 0x1005a4e4
build_tupdesc_ind() at 0x10030c5c
RelationBuildTupleDesc() at 0x10031180
RelationBuildDesc() at 0x100309c0
RelationNameGetRelation() at 0x100337b0
relation_openr() at 0x10014f84
heap_openr() at 0x10014d3c
CatalogCacheInitializeCache() at 0x1000f194
SearchCatCache() at 0x1000fe9c
SearchSysCache() at 0x1000daac
eqsel() at 0x100c5388
OidFunctionCall4() at 0x10045ccc
restriction_selectivity() at 0x100c7594
clauselist_selectivity() at 0x100c72a4
restrictlist_selectivity() at 0x100c7424
set_baserel_size_estimates() at 0x100c8924
set_plain_rel_pathlist() at 0x100e1268
set_base_rel_pathlists() at 0x100e13a4
make_one_rel() at 0x100e1518
subplanner() at 0x100e0b6c
query_planner() at 0x100e0d98
grouping_planner() at 0x100df0f0
subquery_planner() at 0x100dff00
planner() at 0x100dffe0
pg_plan_query() at 0x1001c6b0
pg_exec_query_string() at 0x1001c530
PostgresMain() at 0x1001c0a8
DoBackend() at 0x10003380
BackendStartup() at 0x1000287c
ServerLoop() at 0x10002be8
PostmasterMain() at 0x10004934
main() at 0x100004ec
(dbx) 

> I said:
> > Now that I think a little more, I am worried about the idea that the
> > same thing could potentially happen in other modules that access shared
> > memory and use spinlocks to serialize the access.  Perhaps the fix I
> > applied was wrong, and the correct fix is to change S_LOCK from
> > #define S_UNLOCK(lock)        (*(lock) = 0)
> > to
> > #define S_UNLOCK(lock)        (*((volatile slock_t *) (lock)) = 0)
> 
> I have applied this patch also, since on reflection it seems the clearly
> Right Thing.  However, I find that AIX 5's compiler must have the LWLock
> pointers marked volatile as well, else it still generates bad code.
> 
> Original assembly code fragment (approximately lines 244-271 of
> lwlock.c):
> 
>     l    r3,8(r25)
>     stb    r24,44(r25)
>     cmpi    0,r0,0
>     stb    r4,45(r25)
>     st    r23,48(r25)
>     cal    r5,0(r0)
>     stx    r23,r28,r27                <----- spinlock release
>     bc    BO_IF_NOT,CR0_EQ,__L834
>     st    r25,12(r26)                <----- store into lock->head
>     st    r25,16(r26)                <----- store into lock->tail
>     l    r4,12(r25)
>     bl    .IpcSemaphoreLock{PR}
> 
> With "volatile" added in S_UNLOCK:
> 
>     stb    r24,44(r25)
>     stb    r3,45(r25)
>     cmpi    0,r0,0
>     cal    r5,0(r0)
>     st    r23,48(r25)
>     bc    BO_IF_NOT,CR0_EQ,__L81c
>     st    r25,12(r26)                <----- store into lock->head
>     stx    r23,r28,r27                <----- spinlock release
>     l    r3,8(r25)
>     st    r25,16(r26)                <----- store into lock->tail
>     l    r4,12(r25)
>     bl    .IpcSemaphoreLock{PR}
> 
> With "volatile" lock pointer in LWLockAcquire:
> 
>     stb    r25,44(r23)
>     stb    r3,45(r23)
>     cmpi    0,r0,0
>     cal    r5,0(r0)
>     st    r24,48(r23)
>     bc    BO_IF_NOT,CR0_EQ,__L850
>     st    r23,12(r26)                <----- store into lock->head
>     st    r23,16(r26)                <----- store into lock->tail
>     stx    r24,r28,r27                <----- spinlock release
>     l    r3,8(r23)
>     l    r4,12(r23)
>     bl    .IpcSemaphoreLock{PR}
> 
> I believe the second of these cases is inarguably a compiler bug.
> It is moving a store (into lock->tail) across a store through a
> volatile-qualified pointer.  As I read the spec, that's not kosher.
> 
>             regards, tom lane
>