Thread: V8.0rc1 On AIX.
AIX 5.1 I applied Bruce's patch, configured with --enable-thread-safety and everything went smoothly. > ====================== > All 96 tests passed. > ====================== Brad.
Am Dienstag, 14. Dezember 2004 16:51 schrieb Brad Nicholson: > AIX 5.1 > > I applied Bruce's patch, configured with --enable-thread-safety and > everything went smoothly. Nonetheless, threading support on AIX being a new feature, I don't think this should go into 8.0.0. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote: > Am Dienstag, 14. Dezember 2004 16:51 schrieb Brad Nicholson: > > AIX 5.1 > > > > I applied Bruce's patch, configured with --enable-thread-safety and > > everything went smoothly. > > Nonetheless, threading support on AIX being a new feature, I don't think this > should go into 8.0.0. Huh, isn't this port testing? Do we not want to fix port bugs at this stage? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian wrote: > Huh, isn't this port testing? Do we not want to fix port bugs at > this stage? We are not really fixing anything, because it was never expected to work before. We are adding new functionality. It is, of course, a borderline case. But for example, do we have any information about whether what is being implemented actually works? I don't want to find out in two weeks, that yes, we managed to compile with thread support, but no, threaded applications still have issues on that platform. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote: > Bruce Momjian wrote: > > Huh, isn't this port testing? Do we not want to fix port bugs at > > this stage? > > We are not really fixing anything, because it was never expected to work > before. We are adding new functionality. It is, of course, a > borderline case. But for example, do we have any information about > whether what is being implemented actually works? I don't want to find > out in two weeks, that yes, we managed to compile with thread support, > but no, threaded applications still have issues on that platform. I assume threads are supposed to work on all platforms that support it. We have new threading detection code in 8.0 so I expected some adjustments. Also, someone pointed out that the problem was reported during beta but I missed it. As far as testing we have to have the users do any testing. The thread testing script already tests threading but the actual compile success is what we are adjusting now. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Dec 14, 2004, at 12:51 PM, Bruce Momjian wrote: > Peter Eisentraut wrote: >> Bruce Momjian wrote: >>> Huh, isn't this port testing? Do we not want to fix port bugs at >>> this stage? >> >> We are not really fixing anything, because it was never expected to >> work >> before. We are adding new functionality. It is, of course, a >> borderline case. But for example, do we have any information about >> whether what is being implemented actually works? I don't want to >> find >> out in two weeks, that yes, we managed to compile with thread support, >> but no, threaded applications still have issues on that platform. > > I assume threads are supposed to work on all platforms that support it. > We have new threading detection code in 8.0 so I expected some > adjustments. Also, someone pointed out that the problem was reported > during beta but I missed it. > > As far as testing we have to have the users do any testing. The thread > testing script already tests threading but the actual compile success > is > what we are adjusting now. And that failure was, as I understand it, to accommodate using /usr/bin/cc because as I mentioned in my port report on an AIX 5.1 system, /usr/bin/cc_r already works as-is. I believe that cc_r just adds -DTHREAD_SAFETY, adds -lpthead, sets a LIBPATH such that /usr/lib/threads preceeds /usr/lib/ so you pick up a thread-safe libc.a (which you don't even necessarily need unless you are assuming some libc functions are thread-safe -- if you are doing higher-level sync yourself, then that might not even be necessary), and cc_r does whatever other default defines, etc are best for a safe multithreaded compilation. As I recall, it used to just be a shell-script wrapper in AIX 4 days. Now, on my AIX 5.1 system, /usr/bin/ cc and cc_r are both just symlinks back to /usr/vac/bin/xlc. The different program names just invoke the different settings. Brad: can you make such a symlink and compile with that?, for example: /home/u/brad/cc_r -> /usr/bin/xlc ./configure CC=/home/u/brad/cc_r .... Certainly, pthreads do generally work on AIX. I've been using them for years. However, I always use cc_r (or xlC_r) for multithreaded apps. Peter has a point that the patch makes it compile, but does it make all necessary adjustments such that everything will always work? I can't answer that. -Travis
That's a good point. Should we just use cc_r for all thread compiles on AIX if they are using cc and not gcc? I am not ready to have the backend compiled with cc_r at this stage so I think this level of support has to wait until 8.1. --------------------------------------------------------------------------- Travis P wrote: > > On Dec 14, 2004, at 12:51 PM, Bruce Momjian wrote: > > > Peter Eisentraut wrote: > >> Bruce Momjian wrote: > >>> Huh, isn't this port testing? Do we not want to fix port bugs at > >>> this stage? > >> > >> We are not really fixing anything, because it was never expected to > >> work > >> before. We are adding new functionality. It is, of course, a > >> borderline case. But for example, do we have any information about > >> whether what is being implemented actually works? I don't want to > >> find > >> out in two weeks, that yes, we managed to compile with thread support, > >> but no, threaded applications still have issues on that platform. > > > > I assume threads are supposed to work on all platforms that support it. > > We have new threading detection code in 8.0 so I expected some > > adjustments. Also, someone pointed out that the problem was reported > > during beta but I missed it. > > > > As far as testing we have to have the users do any testing. The thread > > testing script already tests threading but the actual compile success > > is > > what we are adjusting now. > > And that failure was, as I understand it, to accommodate using > /usr/bin/cc because as I mentioned in my port report on an AIX 5.1 > system, /usr/bin/cc_r already works as-is. > > I believe that cc_r just adds -DTHREAD_SAFETY, adds -lpthead, sets a > LIBPATH such that /usr/lib/threads preceeds /usr/lib/ so you pick up a > thread-safe libc.a (which you don't even necessarily need unless you > are assuming some libc functions are thread-safe -- if you are doing > higher-level sync yourself, then that might not even be necessary), and > cc_r does whatever other default defines, etc are best for a safe > multithreaded compilation. As I recall, it used to just be a > shell-script wrapper in AIX 4 days. > > Now, on my AIX 5.1 system, /usr/bin/ cc and cc_r are both just symlinks > back to /usr/vac/bin/xlc. The different program names just invoke the > different settings. Brad: can you make such a symlink and compile > with that?, for example: > /home/u/brad/cc_r -> /usr/bin/xlc > ./configure CC=/home/u/brad/cc_r .... > > Certainly, pthreads do generally work on AIX. I've been using them for > years. However, I always use cc_r (or xlC_r) for multithreaded apps. > Peter has a point that the patch makes it compile, but does it make all > necessary adjustments such that everything will always work? I can't > answer that. > > -Travis > > > ---------------------------(end of broadcast)--------------------------- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
That would require that xlc be installed. Neither cc, cc_r, xlc, nor xlcc (or maybe it was xlcpp?) are available on the systems Brad and I are using, so that symlink will not work. As a result, _none_ of these may be remotely considered to be "universal answers" on AIX. In effect, there are two models for compiling PostgreSQL on AIX: a) Using the VisualAge C family of compilers, that get named xlc, cc, and cc_r, and b) Using GCC, which means the compiler is called "gcc," and which means that xlc, cc, and cc_r should not be consideredas candidates for command lines. Introducing threading doesn't somehow make "cc_r" available for those of us using GCC. -- (reverse (concatenate 'string "gro.gultn" "@" "enworbbc")) http://www3.sympatico.ca/cbbrowne/unix.html "No, I'm not interested in developing a powerful brain. All I'm after is just a mediocre brain, something like the president of American Telephone and Telegraph Company." -- Alan Turing on the possibilities of a thinking machine, 1943.
Centuries ago, Nostradamus foresaw when twp@castle.fastmail.fm (Travis P) would write: > Now, on my AIX 5.1 system, /usr/bin/ cc and cc_r are both just > symlinks back to /usr/vac/bin/xlc. The different program names just > invoke the different settings. Brad: can you make such a symlink and > compile with that?, for example: > /home/u/brad/cc_r -> /usr/bin/xlc > ./configure CC=/home/u/brad/cc_r .... That would require that xlc be installed. Neither cc, cc_r, xlc, nor xlcc (or maybe it was xlcpp?) are available on the systems Brad and I are using, so that symlink will not work. As a result, _none_ of these may be remotely considered to be "universal answers" on AIX. In effect, there are two models for compiling PostgreSQL on AIX: a) Using the VisualAge C family of compilers, that get named xlc, cc, and cc_r, and b) Using GCC, which means the compiler is called "gcc," and which means that xlc, cc, and cc_r should not be consideredas candidates for command lines. Introducing threading doesn't somehow make "cc_r" available for those of us using GCC. -- (reverse (concatenate 'string "gro.gultn" "@" "enworbbc")) http://www3.sympatico.ca/cbbrowne/unix.html "No, I'm not interested in developing a powerful brain. All I'm after is just a mediocre brain, something like the president of American Telephone and Telegraph Company." -- Alan Turing on the possibilities of a thinking machine, 1943.