Re: 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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Centuries ago, Nostradamus foresaw when twp(at)castle(dot)fastmail(dot)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 considered as
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.

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 considered as
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.