Re: Intermediate report for AIX 5L port

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
>