LinuxPPC problems

Patch applied.

As I mentioned before, I did some trials on my LinuxPPC box last week
end. First I compiled with -O0. To my surprise, things got worse than -
O2. Seems tas() for PPC (storage/buffer/s_lock.c) never works if
compiled with -O0. Included are patches that should fix the problem
(of course I have confirmed -O2 works with this patch).

BTW, here is a platforms/regression test failure(serious one--backend
death) matrix.

FreeBSD LinuxPPC(-O0) LinuxPPC(-O2)

constraints GOOD NG NG
create_function1 GOOD GOOD NG
create_function2 GOOD GOOD NG
select_having NG NG NG
select_views GOOD NG NG
triggers GOOD NG NG

I will look into LinuxPPC problems further.
--
Tatsuo Ishii
t-ishii@sra.co.jp
----------------------------------------------------------------------
*** s_lock.c.orig	Mon Aug 31 16:39:24 1998
--- s_lock.c	Mon Aug 31 17:38:34 1998
***************
*** 95,114 ****

#if defined(PPC)
/* Note: need a nice gcc constrained asm version so it can be inlined */
! int
! tas(volatile slock_t *lock)
{
! 	__asm__("lwarx	5,0,3	\n\
! 			cmpwi	5,0		\n\
! 			bne		fail	\n\
! 			addi	5,5,1	\n\
stwcx.  5,0,3	\n\
!      		beq		success	\n\
! fail:		li		3,1		\n\
! 			blr				\n\
! success:					\n\
! 			li 3,0			\n\
!         	blr				\n\
");
}
#endif /* PPC */
--- 95,117 ----

#if defined(PPC)
/* Note: need a nice gcc constrained asm version so it can be inlined */
! static void
! tas_dummy()
{
! __asm__(" \n\
! .global tas \n\
! tas: \n\
! lwarx 5,0,3 \n\
! cmpwi 5,0 \n\
! bne fail \n\
! addi 5,5,1 \n\
stwcx. 5,0,3 \n\
! beq success \n\
! fail: li 3,1 \n\
! blr \n\
! success: \n\
! li 3,0 \n\
! blr \n\
");
}
#endif /* PPC */

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

BTW, here is a platforms/regression test failure(serious one--backend
death) matrix.

FreeBSD LinuxPPC(-O0) LinuxPPC(-O2)

constraints GOOD NG NG
create_function1 GOOD GOOD NG
create_function2 GOOD GOOD NG
select_having NG NG NG
select_views GOOD NG NG
triggers GOOD NG NG

I will look into LinuxPPC problems further.

Here is current status.

FreeBSD LinuxPPC(-O0) LinuxPPC(-O2)

constraints GOOD NG NG
create_function1 GOOD GOOD GOOD
create_function2 GOOD GOOD GOOD
select_having GOOD GOOD GOOD
select_views GOOD NG NG
triggers GOOD GOOD GOOD

After Bruce's, fix 4 NGs in LinuxPPC(-O2) turned to GOOD. Also, -O0
and -O2 now show same results. Excellent! Thanks Bruce.
--
Tatsuo Ishii
t-ishii@sra.co.jp

Here is current status.

FreeBSD LinuxPPC(-O0) LinuxPPC(-O2)

constraints GOOD NG NG
create_function1 GOOD GOOD GOOD
create_function2 GOOD GOOD GOOD
select_having GOOD GOOD GOOD
select_views GOOD NG NG
triggers GOOD GOOD GOOD

After Bruce's, fix 4 NGs in LinuxPPC(-O2) turned to GOOD. Also, -O0
and -O2 now show same results. Excellent! Thanks Bruce.

Ah, by Tatsuo's measures I'm getting similar results on Linux/i686 as he
is getting on Linux/PPC. I have failures on constraints and
select_index, but neither are core dumps, and both involve not finding
tables (probably index or index cache corruption on pg_class). The other
regression tests which fail are due to tables or information missing
from the tests listed by Tatsuo or myself.

btw, I'm pretty sure that the select_views problem pre-dates the OID and
index patches.

David made the recent observation that my symptoms are likely due to a
damaged index, not a damaged pg_class table. So indices (or something
related) are still suspect. Remember that at least one of my symptoms is
from a table which had been destroyed and then recreated. Don't know if
that is relevant...

The only thing I haven't done yet to refresh source code is to pull a
*completely new* cvs tree from postgresql.org. However, since I'm
getting the same results as Tatsuo I think CVSup is treating me OK, so
won't try that (yet).

Off to work now.

- Tom

Here is current status.

FreeBSD LinuxPPC(-O0) LinuxPPC(-O2)

constraints GOOD NG NG
create_function1 GOOD GOOD GOOD
create_function2 GOOD GOOD GOOD
select_having GOOD GOOD GOOD
select_views GOOD NG NG
triggers GOOD GOOD GOOD

After Bruce's, fix 4 NGs in LinuxPPC(-O2) turned to GOOD. Also, -O0
and -O2 now show same results. Excellent! Thanks Bruce.

Ah, by Tatsuo's measures I'm getting similar results on Linux/i686 as he
is getting on Linux/PPC. I have failures on constraints and
select_index, but neither are core dumps, and both involve not finding
tables (probably index or index cache corruption on pg_class). The other
regression tests which fail are due to tables or information missing
from the tests listed by Tatsuo or myself.

btw, I'm pretty sure that the select_views problem pre-dates the OID and
index patches.

David made the recent observation that my symptoms are likely due to a
damaged index, not a damaged pg_class table. So indices (or something
related) are still suspect. Remember that at least one of my symptoms is
from a table which had been destroyed and then recreated. Don't know if
that is relevant...

The only thing I haven't done yet to refresh source code is to pull a
*completely new* cvs tree from postgresql.org. However, since I'm
getting the same results as Tatsuo I think CVSup is treating me OK, so
won't try that (yet).

I think downloading a new cvs is not worth it. It fixed a problem where
some people had fmgr.h in src/include because it must have been moved
since 6.3.2, and the first person to change the system catalogs(me)
caused the initdb problems.

Don't think it is a problem anymore as the people who had the fmgr.h in
the old location have removed it.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)