Обсуждение: Old source code needed
Hi all, I need to find a old source codes for Postgresql9.0 BETA relases.
could You help me ?
could You help me ?
On 11/26/2015 01:29 PM, NTPT wrote: > Hi all, I need to find a old source codes for Postgresql9.0 BETA relases. > could You help me ? > http://git.postgresql.org/gitweb/?p=postgresql.git;a=tags Then, say for REL9_0_BETA2 click on commit which will take you to: http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=dcd52a64bd9d3baa252a8bea662b08f7780035a1 click on the snapshot link and you will get a postgres*.tar.gz file that is the code at 9.0beta2 -- Adrian Klaver adrian.klaver@aklaver.com
Thanx for help, I grab the source code that match old cluster fs backup.
However: Should it run fine compiled with recent gcc 4.9.3 ?
while compiled with this gcc , I got a lot of strange errors like
ERROR: could not identify an ordering operator for type name at character 3336
HINT: Use an explicit ordering operator or modify the query.
with \dt or \list or other commands and select.
Hovever compiling it with gcc 3.4.6 and everythig works.
Is it intended (expected) behavior or a compiller bug (Being on Gentoo, compiller bug scary me a lot).
thanx
However: Should it run fine compiled with recent gcc 4.9.3 ?
while compiled with this gcc , I got a lot of strange errors like
ERROR: could not identify an ordering operator for type name at character 3336
HINT: Use an explicit ordering operator or modify the query.
with \dt or \list or other commands and select.
Hovever compiling it with gcc 3.4.6 and everythig works.
Is it intended (expected) behavior or a compiller bug (Being on Gentoo, compiller bug scary me a lot).
thanx
---------- Původní zpráva ----------
Od: Adrian Klaver <adrian.klaver@aklaver.com>
Komu: NTPT <NTPT@seznam.cz>, pgsql-general@postgresql.org
Datum: 26. 11. 2015 22:49:13
Předmět: Re: [GENERAL] Old source code needed
On 11/26/2015 01:29 PM, NTPT wrote:
> Hi all, I need to find a old source codes for Postgresql9.0 BETA relases.
> could You help me ?
>
http://git.postgresql.org/gitweb/?p=postgresql.git;a=tags
Then, say for REL9_0_BETA2 click on commit which will take you to:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=dcd52a64bd9d3baa252a8bea662b08f7780035a1
click on the snapshot link and you will get a postgres*.tar.gz file that
is the code at 9.0beta2
--
Adrian Klaver
adrian.klaver@aklaver.com
On 2015-11-27 4:31 AM, NTPT wrote: > Thanx for help, I grab the source code that match old cluster fs > backup. > > However: Should it run fine compiled with recent gcc 4.9.3 ? You realize how old 9.0 is, right? And you understand how nonsensical your question is? How can you guarantee that code compiles properly on a compiler which is released years after you write the code? > > while compiled with this gcc , I got a lot of strange errors like > > ERROR: could not identify an ordering operator for type name at > character 3336 > HINT: Use an explicit ordering operator or modify the query. > > with \dt or \list or other commands and select. > > > Hovever compiling it with gcc 3.4.6 and everythig works. > > Is it intended (expected) behavior or a compiller bug (Being on > Gentoo, compiller bug scary me a lot). > > thanx > jan
On 11/27/2015 06:24 AM, Jan de Visser wrote: > > > On 2015-11-27 4:31 AM, NTPT wrote: >> Thanx for help, I grab the source code that match old cluster fs >> backup. >> >> However: Should it run fine compiled with recent gcc 4.9.3 ? > > You realize how old 9.0 is, right? And you understand how nonsensical > your question is? How can you guarantee that code compiles properly on a > compiler which is released years after you write the code? To me nonsensical would be trying to compile newer code using an old compiler. What the OP did seemed to be in the realm of possibility as I would think backwards compatibility kicks in. > >> >> while compiled with this gcc , I got a lot of strange errors like >> >> ERROR: could not identify an ordering operator for type name at >> character 3336 >> HINT: Use an explicit ordering operator or modify the query. >> >> with \dt or \list or other commands and select >> >> >> Hovever compiling it with gcc 3.4.6 and everythig works. >> >> Is it intended (expected) behavior or a compiller bug (Being on >> Gentoo, compiller bug scary me a lot). >> >> thanx >> > > jan > > -- Adrian Klaver adrian.klaver@aklaver.com
On 2015-11-27 9:44 AM, Adrian Klaver wrote: >> You realize how old 9.0 is, right? And you understand how nonsensical >> your question is? How can you guarantee that code compiles properly on a >> compiler which is released years after you write the code? > > To me nonsensical would be trying to compile newer code using an old > compiler. What the OP did seemed to be in the realm of possibility as > I would think backwards compatibility kicks in. Well, maybe. But there's no way to *guarantee* it will work. And apparently it doesn't. It's not unheard of - I have some C code which I developed over the last year or so on gcc 4.9. When I first attempted to compile it on 5.2 it failed horrible. And there's no real unusual things I'm doing - I didn't even use C11, just C99.
Jan de Visser <jan@de-visser.net> writes:
> On 2015-11-27 9:44 AM, Adrian Klaver wrote:
>> To me nonsensical would be trying to compile newer code using an old
>> compiler. What the OP did seemed to be in the realm of possibility as
>> I would think backwards compatibility kicks in.
> Well, maybe. But there's no way to *guarantee* it will work. And
> apparently it doesn't.
AFAICT, backwards compatibility is not something the gcc boys care about.
I suspect the particular complaint here is related to
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: REL9_1_STABLE Release: REL9_1_10 [649839dd9] 2013-08-21 18:31:48 -0400
Branch: REL9_0_STABLE Release: REL9_0_14 [e9e387a5b] 2013-08-21 18:31:51 -0400
Branch: REL8_4_STABLE Release: REL8_4_18 [8396d230f] 2013-08-21 18:31:54 -0400
Disable -faggressive-loop-optimizations in gcc 4.8+ for pre-9.2 branches.
With this optimization flag enabled, recent versions of gcc can generate
incorrect code that assumes variable-length arrays (such as oidvector)
are actually fixed-length because they're embedded in some larger struct.
The known instance of this problem was fixed in 9.2 and up by commit
8137f2c32322c624e0431fac1621e8e9315202f9 and followon work, which hides
actually-variable-length catalog fields from the compiler altogether.
And we plan to gradually convert variable-length fields to official
"flexible array member" notation over time, which should prevent this type
of bug from reappearing as gcc gets smarter. We're not going to try to
back-port those changes into older branches, though, so apply this
band-aid instead.
Andres Freund
though there are certainly other places that we've had to change because
newer versions of gcc broke them.
regards, tom lane
On 2015-11-27 10:31:03 +0100, NTPT wrote: > Thanx for help, I grab the source code that match old cluster fs backup. > > However: Should it run fine compiled with recent gcc 4.9.3 ? > > while compiled with this gcc , I got a lot of strange errors like > > ERROR: could not identify an ordering operator for type name at character > 3336 > HINT: Use an explicit ordering operator or modify the query. > > with \dt or \list or other commands and select. > > > Hovever compiling it with gcc 3.4.6 and everythig works. > > Is it intended (expected) behavior or a compiller bug (Being on Gentoo, > compiller bug scary me a lot). This has been fixed later in the 9.0 branch = but as you want to checkout a specific tag, that's not goign to help you... What are you actually trying to do? Andres