Thread: Patches for Postgresql on Linux/Alpha!
Ok, they are finally here.... This is an initial release to just
the pgsql lists. If no one sees any problems with the below announcement
or patches, I will then forward them on to the rest of the world (save for
the RH pgsql packager, as I do not have his email address). Also, as
others see fit, maybe the patches should be put on the FTP site, and maybe
a small annoucement somewhere on the web site, so people can find the
patches, even if they missed them on the mailing lists.
-------------
Attached are patches to fix about 99% of the problems that exist
with PostgreSQL on Alpha's running Linux. They have not been heavily
tested, but from what testing has been done, they appear to fix a number
of nagging problems in the Alpha port of PostgreSQL.
These patches are against the 6.5.1 release tarball as available
from ftp.postgresql.org. When applied, the resulting binaries pass all
regression tests save for two:
geometry: Minor off by one error in the last decimal place. Can be
safely ignored provided you don't need extreme accuracy.
rules: Minor quirk in that PostgreSQL on Alpha has a different
default sorting order than the platform original used to
generate the expected regression results. Can be safely ignored.
Unaligned traps are still present in a moderate amount with PostgreSQL on
Linux/Alpha. To give one a feeling of the number, 28 were generated from a
run of the regression tests. These are being worked on and should be
resolved in the future.
Therefore, everyone with an Alpha running Linux and interested in
running an excellent SQL database, download the 6.5.1 source for
PostgreSQL, apply the patches, compile it, and pound on it. Send
reactions, evaluations, problems to either me, the Debian Alpha list,
Red Hat Alpha list, or even the PostgreSQL ports list and I will see them.
Because the extensive changes these patches make to the main
PostgreSQL source tree, they are being and will be provided seperately for
the 6.5.x releases. It is planned to roll them into the main distribution
source tree for the 6.6 release that is down the road a couple of months.
Lastly, these patches are also available from my web site (see
address in sig), where I will also be posting any future updates.
PS. Uncle George (often spotted on the RedHat axp-list) is the one
to thank for the bulk of these patches. The rest is a combined mix of
fixes by both Bruce Momjian and myself.
----------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
----------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | rkirkpat@nag.cs.colorado.edu |
----------------------------------------------------------------------------
| http://www-ugrad.cs.colorado.edu/~rkirkpat/ |
----------------------------------------------------------------------------
Attachment
Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu> writes:
> Ok, they are finally here.... This is an initial release to just
> the pgsql lists. If no one sees any problems with the below announcement
> or patches, I will then forward them on to the rest of the world (save for
> the RH pgsql packager, as I do not have his email address). Also, as
> others see fit, maybe the patches should be put on the FTP site, and maybe
> a small annoucement somewhere on the web site, so people can find the
> patches, even if they missed them on the mailing lists.
OK, after a *real* quick once-over, it certainly seems that 99% of the
bulk is changes for the fmgr interface problem (although it looks like
int32s were changed to Datum also? Is that really needed on Alpha?)
I see a few hacks on time_t that I am worried about; those will almost
certainly cause problems for other architectures if not ifdef'd.
As I commented before, I would like to think about a different solution
to the fmgr problem for 6.6, so I'd like to hold off committing any of
these fmgr changes into the current tree until we have a consensus on
what the best approach is. But we could commit them into the 6.5 branch
after sufficient testing. That would be nice for PPC folks as well, as
I'll bet these changes would let them run with more than -O0 ...
regards, tom lane
> As I commented before, I would like to think about a different solution > to the fmgr problem for 6.6, so I'd like to hold off committing any of > these fmgr changes into the current tree until we have a consensus on > what the best approach is. But we could commit them into the 6.5 branch > after sufficient testing. That would be nice for PPC folks as well, as > I'll bet these changes would let them run with more than -O0 ... Yes. I would love to see your solution! BTW, What about HP-UX? Are they having similar problems with -O2? --- Tatsuo Ishii
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
>> As I commented before, I would like to think about a different solution
>> to the fmgr problem for 6.6,
> Yes. I would love to see your solution!
I posted some preliminary ideas to the hackers list on 6/14/99 (see
message titled "Cleaning up function interface"). I think the fmgr
interface is in need of thorough redesign. Aside from the portability
bugs that we are currently getting our noses rubbed in, it cannot handle
NULL function arguments or results properly.
Something I didn't talk about in my earlier message, but am getting
more interested in doing: I would like to see if we can't make float4
a pass-by-value type, and float8 and int8 as well when on a platform
where Datum is 8 bytes wide. 64-bit platforms are going to become
the norm over the next few years, and Postgres shouldn't be forever
tied to palloc() overhead for passing and returning datatypes that
don't need it on newer platforms. I think that with suitably chosen
macros for accessing and returning function arguments/results, it
would be possible for the bulk of the source code not to be aware of
whether a particular C datatype is pass by value or pass by reference
in the fmgr interface.
In short, I think there are enough reasons for redoing the fmgr
interface from scratch that we ought to just bite the bullet and do it,
tedious though it will be.
The only real argument against it is that it'd break existing user code
in loadable libraries; people with user-defined functions written in C
would have to revise 'em. That's certainly a bad negative, but I think
the positives outweigh it. That existing user code will need to
change anyway to be ported to one of the platforms where parameter-
passing problems exist :-(
> BTW, What about HP-UX? Are they having similar problems with -O2?
On the newer 64-bit machines, I wouldn't be at all surprised. But
Mike Schout just reported regression tests passing on his 64-bit box,
so maybe we're still OK there. For now anyway...
regards, tom lane
On Fri, 30 Jul 1999, Tom Lane wrote:
> OK, after a *real* quick once-over, it certainly seems that 99% of the
> bulk is changes for the fmgr interface problem (although it looks like
> int32s were changed to Datum also? Is that really needed on Alpha?)
>
> I see a few hacks on time_t that I am worried about; those will almost
> certainly cause problems for other architectures if not ifdef'd.
I have hardly looked at the patch in detail at all, so I can't
respond to your specific observation at this time. I just wanted something
that made at least alpha work out the door first, and then go back and
review the patch in detail to add #ifdef (__alpha__) as needed.
> As I commented before, I would like to think about a different solution
> to the fmgr problem for 6.6, so I'd like to hold off committing any of
> these fmgr changes into the current tree until we have a consensus on
> what the best approach is. But we could commit them into the 6.5 branch
> after sufficient testing. That would be nice for PPC folks as well, as
> I'll bet these changes would let them run with more than -O0 ...
I never asked for these patches to be put in the pgsql source tree
in anyway. This is just so people who want to run 6.5.1 on Linux/Alpha
will be able to, with a relatively clean and well working binary. The
patches for the pgsql source tree will be trickling in over the next few
months as I evaluate the alpha patches in detail.
----------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
----------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | rkirkpat@nag.cs.colorado.edu |
----------------------------------------------------------------------------
| http://www-ugrad.cs.colorado.edu/~rkirkpat/ |
----------------------------------------------------------------------------
> ... I will then forward them on to the rest of the world (save for
> the RH pgsql packager, as I do not have his email address).
That would be Lamar and myself, until we have validated it for the RPM
build. We'll take it from there...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California