Обсуждение: Re: [PORTS] RedHat6.0 & Alpha
> > I imagine that this flag is specific to the compiler. It would > > probably be best to leave it to patches until the alpha issues are > > solved for every OS environment; sorry I don't have a platform myself > > to test on. > > > > btw, RedHat is interested in doing a maintenance release of Postgres > > rpms, and would dearly love to have the Alpha port problems solved (or > > vica versa; they hate that their shipping rpms are broken or not > > available on one of their three supported architectures). > > > > Uncle G, could you tell us the actual port string configure generates > > for your platform? At the moment, PORTNAME on my i686 box says > > "linux", and I don't see architecture info. But perhaps we can have > > configure deduce an ARCH parameter too? It already knows it when first > > identifying the system... > > OK, I have made it: > > ifeq ($(CPU),alpha) > ifeq ($(CC), gcc) > CFLAGS+= -mieee > endif > ifeq ($(CC), egcs) > CFLAGS+= -mieee > endif > endif > > I can always rip it out later. Let me reiterate Thomas's comments on this. Alpha has been a very bad port for us. I realize the problems are complex, but each alpha person seems to know only 80% of what we need to get things working 100%. We get partial solutions to small problems, that just seem to fix things long enough for current release. We had one release that would not even initdb on alpha. We really need alpha folks to get their noses to the grindstones and give us some solid causes/fixes to their problems. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Ok,
I would have liked to have seen the fix to typedef time_t AbsoluteTime in
nabstime.h, rather than this, but i guess its some movement :-/
As per ur request, I am sending u ( bruce) my changed *.[ch] files from the
July 20 source ( they are not diffs ) . All the regressions tests work except
for geometry ( precision ? ) and Rules ( of which i will follow up (later)
with a question.
I u folks got any questions please let me know, As i'm sure that you will
have some.
Regarding the Test&set problems, u have to compile spin.c with -fno-inline.
i'd give u a makefile but i'm not sure how u folks are handling the
ifeq ($(OS), linux )
ifeq ($(CPU), alpha )
spin.o: spin.c
$(CC) $(CFLAGS) -c -fno-inline spin.c -o spin.o
endif
endif
I'm using -O3, and seems happy
gat
Bruce Momjian wrote:
> > > I imagine that this flag is specific to the compiler. It would
> > >
> > OK, I have made it:
> >
> > ifeq ($(CPU),alpha)
> > ifeq ($(CC), gcc)
> > CFLAGS+= -mieee
> > endif
> > ifeq ($(CC), egcs)
> > CFLAGS+= -mieee
> > endif
> > endif
> >
> > I can always rip it out later.
>
> Let me reiterate Thomas's comments on this. Alpha has been a very
> bad port for us. I realize the problems are complex, but each alpha
> person seems to know only 80% of what we need to get things working
> 100%. We get partial solutions to small problems, that just seem to
In rules.out it appears that the sort order is wrong. The SELECT * FROM shoe_ready WHERE total_avail >= 2; first give a sh3, and then a sh1. Can someone tell me where/or how the sorting is accomplished ? This presumes that some sorting is done. gat BTW this appears to work on the redhat/i386 port . SO where has my alpha gone wrong :-( QUERY: SELECT * FROM shoelace ORDER BY sl_name; sl_name |sl_avail|sl_color |sl_len|sl_unit |sl_len_cm ----------+--------+----------+------+--------+--------- sl1 | 5|black | 80|cm | 80 sl2 | 6|black | 100|cm | 100 sl3 | 0|black | 35|inch | 88.9 sl4 | 8|black | 40|inch | 101.6 sl5 | 4|brown | 1|m | 100 sl6 | 0|brown | 0.9|m | 90 sl7 | 7|brown | 60|cm | 60 sl8 | 1|brown | 40|inch | 101.6 (8 rows) QUERY: SELECT * FROM shoe_ready WHERE total_avail >= 2; shoename |sh_avail|sl_name |sl_avail|total_avail ----------+--------+----------+--------+----------- sh3 | 4|sl7 | 7| 4 sh1 | 2|sl1 | 5| 2 (2 rows) ~ ~
> > I'm using -O3, and seems happy Can I now put back optimization to -O2 on alpha? Please send me your other diffs. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> Ok,
> I would have liked to have seen the fix to typedef time_t AbsoluteTime in
> nabstime.h, rather than this, but i guess its some movement :-/
It is on our list. Too late to get that into 6.5.1:
* Make Absolutetime/Relativetime int4 because time_t can be int8 on some ports
> As per ur request, I am sending u ( bruce) my changed *.[ch] files from the
> July 20 source ( they are not diffs ) . All the regressions tests work except
> for geometry ( precision ? ) and Rules ( of which i will follow up (later)
> with a question.
I will not accept non-diff files. See tools/make_diff or use cvs diff.
Is this the kind of Alpha support I get? :-;
> I u folks got any questions please let me know, As i'm sure that you will
> have some.
>
> Regarding the Test&set problems, u have to compile spin.c with -fno-inline.
> i'd give u a makefile but i'm not sure how u folks are handling the
> ifeq ($(OS), linux )
> ifeq ($(CPU), alpha )
> spin.o: spin.c
> $(CC) $(CFLAGS) -c -fno-inline spin.c -o spin.o
> endif
> endif
>
> I'm using -O3, and seems happy
> gat
I have added to backend/storage/ipc/Makefile:
# seems to be required 1999/07/22 bjm
ifeq ($(CPU),alpha)
ifeq ($(CC), gcc)
CFLAGS+= -fno-inline
endif
ifeq ($(CC), egcs)
CFLAGS+= -fno-inline
endif
endif
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
I dont know.
u seem to want to inflict -fno-inline on all modules, which was not my
fix for the test&set problem. I just wanted the -fno-inline to be set for
only spin.c, which is the only module on redhat linux/alpha to have this
particular problem.
Bruce Momjian wrote:
> >
> > I'm using -O3, and seems happy
>
> Can I now put back optimization to -O2 on alpha? Please send me your
> other diffs.
>
> I dont know. > u seem to want to inflict -fno-inline on all modules, which was not my > fix for the test&set problem. I just wanted the -fno-inline to be set for > only spin.c, which is the only module on redhat linux/alpha to have this > particular problem. > Can't really hurt to put it on all files in a directory. I hesistate to put per-file flags. It is bad enough we are doing per-directory flags. If you see any performance difference on per directory vs. per file, I will change it, ok? -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Thu, 22 Jul 1999, Uncle George wrote:
> As per ur request, I am sending u ( bruce) my changed *.[ch] files from the
> July 20 source ( they are not diffs ) . All the regressions tests work except
> for geometry ( precision ? ) and Rules ( of which i will follow up (later)
> with a question.
Sounds great! Would you please send the changed *.[ch] files to me
(only, no need to echo to the rest of the list) as well, I would like to
try them out.
Also, if you don't feel like making diffs, I can make them (once I
get your changed filed) and send them back to Bruce.
Finally, we are getting somewhere on the Pgsql Linux/Alpha port!!!
:)
----------------------------------------------------------------------------
| "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/ |
----------------------------------------------------------------------------
> On Thu, 22 Jul 1999, Uncle George wrote: > > > As per ur request, I am sending u ( bruce) my changed *.[ch] files from the > > July 20 source ( they are not diffs ) . All the regressions tests work except > > for geometry ( precision ? ) and Rules ( of which i will follow up (later) > > with a question. > > Sounds great! Would you please send the changed *.[ch] files to me > (only, no need to echo to the rest of the list) as well, I would like to > try them out. > Also, if you don't feel like making diffs, I can make them (once I > get your changed filed) and send them back to Bruce. > Finally, we are getting somewhere on the Pgsql Linux/Alpha port!!! > :) Ryan, I just sent you the diffs I received. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Thu, 22 Jul 1999, Bruce Momjian wrote:
> > Sounds great! Would you please send the changed *.[ch] files to me
> > (only, no need to echo to the rest of the list) as well, I would like to
> > try them out.
>
> Ryan, I just sent you the diffs I received.
Got them, Thanks! I will check them out tomorrow and let you know
how I fair with them. TTYL.
----------------------------------------------------------------------------
| "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/ |
----------------------------------------------------------------------------
> The SELECT * FROM shoe_ready WHERE total_avail >= 2;
> first give a sh3, and then a sh1.
> BTW this appears to work on the redhat/i386 port . SO where has my
> alpha gone wrong :-(
It's not wrong. If there is no explicit order-by, your system is
entitled to return results in any damn order it wants to. The result
as a set is quite correct (barring other unreported troubles)...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Thanks,
But I think that a computer has no right to any "damn order" it
wants to, particular if its the same src & test facilities.
gat
shutup HAL, you will get you're chance to talk to these guys later.
Thomas Lockhart wrote:
> > The SELECT * FROM shoe_ready WHERE total_avail >= 2;
> > first give a sh3, and then a sh1.
> > BTW this appears to work on the redhat/i386 port . SO where has my
> > alpha gone wrong :-(
>
> It's not wrong. If there is no explicit order-by, your system is
> entitled to return results in any damn order it wants to. The result
> as a set is quite correct (barring other unreported troubles)...
On Fri, Jul 23, 1999 at 07:26:03AM -0400, Uncle George wrote: > Thanks, > But I think that a computer has no right to any "damn order" it > wants to, particular if its the same src & test facilities. > gat Thomas' reply is quite correct. Unless you specify an order, the underlying system (maybe not even postgresql, but the OS and libraries it uses) may sort and return comparisons in any order, but always a consistent order. The fact that an i386 and an alpha processor based systems return results differently should be of no suprise. You must explicitly specify "ORDER BY xxx" in a query, and even then you need to know your collation sequences etc. Regards, -- Peter Galbavy Knowledge Matters Ltd http://www.knowledge.com/
> But I think that a computer has no right to any "damn order" it
> wants to, particular if its the same src & test facilities.
Now that you mention it, it isn't the same source since we use some
Unix library sorting routines. It is fairly common for us to see
ordering differences between platforms, which is why you see so many
"order by" clauses in the regression tests. We can add one more (send
patches? :) and you would never know there was a difference in
underlying behavior...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
> Thanks, > But I think that a computer has no right to any "damn order" it > wants to, particular if its the same src & test facilities. > gat I totally disagree. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Thanks,
But as I said before, with the same src, & tests, same collating
seq, same lang, same 'c' compiler , and same ..........., u'd expect to
get the same results. If u don't, as i have found out, there is an
inconsistency in the PORT, libraries, etc ( whatever ) .
I can go to upgrade to RH6.0/i386( mine is RH5.2 ) and see if is
the same as the RH6.0/alpha, but I really suspect it will (still ) be
different ( as the RH5.2/i386 matches expected/rules.out ).
Therefor to resolve this inconsistency, I would like to know where
the output get ( or gets not ) sorted properly. Any suggestions ?
Linux, et al, is suppose to be consistent on all platforms, and a
lot of people try very hard to get each linux port in-line with all
other ports. I dont percieve postgresql as being any different on any
other linux/( intel/alpha/ppc/sparc/mips ) machine. So I have said, so
shall it be done. ( :-) )
gat
Thomas Lockhart wrote:
> > But I think that a computer has no right to any "damn order" it
> > wants to, particular if its the same src & test facilities.
>
> Now that you mention it, it isn't the same source since we use some
> Unix library sorting routines. It is fairly common for us to see
> ordering differences between platforms, which is why you see so many
> "order by" clauses in the regression tests. We can add one more (send
> patches? :) and you would never know there was a difference in
> underlying behavior...
>
> - Thomas
On the July 26 snapshot, I have not seen the changes to the postgresql/alpha port. Although u can reiterate as much as u want, I percieve no particular direction by u folks to get the alpha port done 100%. I haven't even been asked any questions about the alpha patches. Over the weekend I have resolved the problems with rules.sql, and despite your assurances, I have resolved it to a postgresql peculiarity dealing with Cost. Anyway, I have to move on, and just cant wait. Lemme know when u have applied/ resolved what to do with the patches. gat Bruce Momjian wrote: > > > Let me reiterate Thomas's comments on this. Alpha has been a very > bad port for us. I realize the problems are complex, but each alpha > person seems to know only 80% of what we need to get things working > 100%. We get partial solutions to small problems, that just seem to > fix things long enough for current release. We had one release that > would not even initdb on alpha. We really need alpha folks to get their > noses to the grindstones and give us some solid causes/fixes to their > problems. >
> On the July 26 snapshot, I have not seen the changes to the postgresql/alpha > port. Although u can reiterate as much as u want, I percieve no particular > direction by u folks to get the alpha port done 100%. I haven't even been > asked any questions about the alpha patches. > > Over the weekend I have resolved the problems with rules.sql, and despite > your assurances, I have resolved it to a postgresql peculiarity dealing with > Cost. > > Anyway, I have to move on, and just cant wait. Lemme know when u have > applied/ resolved what to do with the patches. > gat > Thanks. We are getting over the 6.5.* releases, and are relaxing a little, seeing as 6.6 is months away. I will certainly let you know when the patches are applied. Thanks. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> > > Sounds great! Would you please send the changed *.[ch] files to me
> > Ryan, I just sent you the diffs I received.
> Got them, Thanks! I will check them out tomorrow and let you know
> how I fair with them. TTYL.
Where are we on the Alpha port? Once we have some reasonable behavior,
I'd like to build some source RPMs which contain the patches. They do
not have to be applied to the main tree if that is premature, but once
they are put into a source RPM then Uncle G can build some binary RPMs
for Alpha and try them out.
RedHat will release new RPMs when the Alpha port works, since they're
anxious that the Alpha is supported...
As an aside, I've just posted Intel RPMs for v6.5.1 on
ftp://postgresql.org/pub/{RPMS,SRPMS}/*.rpm
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
> > > > Sounds great! Would you please send the changed *.[ch] files to me
> > > Ryan, I just sent you the diffs I received.
> > Got them, Thanks! I will check them out tomorrow and let you know
> > how I fair with them. TTYL.
>
> Where are we on the Alpha port? Once we have some reasonable behavior,
> I'd like to build some source RPMs which contain the patches. They do
> not have to be applied to the main tree if that is premature, but once
> they are put into a source RPM then Uncle G can build some binary RPMs
> for Alpha and try them out.
>
> RedHat will release new RPMs when the Alpha port works, since they're
> anxious that the Alpha is supported...
>
> As an aside, I've just posted Intel RPMs for v6.5.1 on
>
> ftp://postgresql.org/pub/{RPMS,SRPMS}/*.rpm
I just bounced the alpha patch over to you, Thomas. If you like it, it
can be applied.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> I just bounced the alpha patch over to you, Thomas. If you like it, it
> can be applied.
Great. But I'm looking for feedback from Ryan if he has a chance to
test it.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
On Tue, 27 Jul 1999, Thomas Lockhart wrote:
> > I just bounced the alpha patch over to you, Thomas. If you like it, it
> > can be applied.
>
> Great. But I'm looking for feedback from Ryan if he has a chance to
> test it.
Sorry, I have been a bit busy over the weekend. I did get to test
it on Friday though. The patch applied flawlessly to that day's snapshot.
Though I quickly hit a minor, but annoying snag. The configure script
detects my XLT 366 Alpha's CPU as 'alphaev5', which means that none of the
alpha conditional clauses in the makefiles get evaluated correctly, and
one ends up with a binary that gets stuck spinlocks (when using -O2 for
CFLAGS).
I couldn't find anyway to tell make to look for alpha only at the
start of the CPU string (i.e. '$CPU =~ /^alpha.*/' in perl syntax), but
there might be one I missed. I simply ran configure, then edited
makefile.global, and changed 'alphaev5' to 'alpha' and complied as usual.
This time it worked great! No stuck spinlocks (and -O2 was used!),
and all the regression tests, saved for rules as Uncle G. has already
mentioned.
So, other than the CPU type detection problem, everything looks
very good. I have given postgres a decent work out, loading large data
sets (8 tables, 88k records), and then accessing via a web interface I am
writing for work, without any problems at all.
If no one minds, I will forward Uncle G.'s patches onto some
Debian-Alpha hackers that contacted me a while back about the status of
pgsql on alphas, and see what reaction they have to them.
TTYL.
----------------------------------------------------------------------------
| "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/ |
----------------------------------------------------------------------------
> > Great. But I'm looking for feedback from Ryan if he has a chance to
> > test it.
> Sorry, I have been a bit busy over the weekend. I did get to test
> it on Friday though. The patch applied flawlessly to that day's snapshot.
> Though I quickly hit a minor, but annoying snag. The configure script
> detects my XLT 366 Alpha's CPU as 'alphaev5', which means that none of the
> alpha conditional clauses in the makefiles get evaluated correctly, and
> one ends up with a binary that gets stuck spinlocks (when using -O2 for
> CFLAGS).
> I couldn't find anyway to tell make to look for alpha only at the
> start of the CPU string (i.e. '$CPU =~ /^alpha.*/' in perl syntax), but
> there might be one I missed. I simply ran configure, then edited
> makefile.global, and changed 'alphaev5' to 'alpha' and complied as usual.
Hmm. That can probably be worked around with an entry in
Makefile.custom, though I haven't looked at the specific usage.
> This time it worked great! No stuck spinlocks (and -O2 was used!),
> and all the regression tests, saved for rules as Uncle G. has already
> mentioned.
Fantastic.
> So, other than the CPU type detection problem, everything looks
> very good. I have given postgres a decent work out, loading large data
> sets (8 tables, 88k records), and then accessing via a web interface I am
> writing for work, without any problems at all.
> If no one minds, I will forward Uncle G.'s patches onto some
> Debian-Alpha hackers that contacted me a while back about the status of
> pgsql on alphas, and see what reaction they have to them.
Forwarding the patches is good. Is there anything in them which could
possibly damage a non-alpha machine? If not, and if they are on the
right track (they must be, since things actually work finally :) then
they should eventually end up in our main tree.
In glancing through the patches, I notice that one change is to pass
"Datum" to all ADT functions which take a char, int2, or int4. That
certainly makes the code uglier, but I can see that fudging the calls
as we did earlier might have led to trouble.
In the meantime, they could end up in Linux RPMs as patches to the
pristine distribution, and could be in new RPMs released through
RedHat. They will be very excited (or at least as excited as they
get... ;)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
On Wed, 28 Jul 1999, Thomas Lockhart wrote:
> > This time it worked great! No stuck spinlocks (and -O2 was used!),
> > and all the regression tests, saved for rules as Uncle G. has already
> > mentioned.
>
> Fantastic.
One thing I did forget to mention, is that I am getting a decent
handful of unaligned traps from postmaster. To put a number on that, from
running the regression tests three times, once with numeric_big enabled, I
got ~164 unaligned traps.
Not a show stopper, but something that probably needs to looked
into at some point in order to maximize performance of pgsql on Alphas.
> Forwarding the patches is good. Is there anything in them which could
> possibly damage a non-alpha machine? If not, and if they are on the
> right track (they must be, since things actually work finally :) then
> they should eventually end up in our main tree.
I will pass the patches on to the Debian people and see what their
experience is with them. I know they have a handful of patches they
already apply to pgsql as it is (mostly reorganization of files I think),
so to add one more won't cause them too much more trouble for the time
being.
> In the meantime, they could end up in Linux RPMs as patches to the
> pristine distribution, and could be in new RPMs released through
> RedHat. They will be very excited (or at least as excited as they
> get... ;)
And something similar for the debian packages as well. I will make
sure the debian peple get the patches, though I will leave the
responsiblity of getting the patches to the redhat people to someone else.
:) TTYL.
----------------------------------------------------------------------------
| "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/ |
----------------------------------------------------------------------------
> On Wed, 28 Jul 1999, Thomas Lockhart wrote: > > > > This time it worked great! No stuck spinlocks (and -O2 was used!), > > > and all the regression tests, saved for rules as Uncle G. has already > > > mentioned. > > > > Fantastic. > > One thing I did forget to mention, is that I am getting a decent > handful of unaligned traps from postmaster. To put a number on that, from > running the regression tests three times, once with numeric_big enabled, I > got ~164 unaligned traps. > Not a show stopper, but something that probably needs to looked > into at some point in order to maximize performance of pgsql on Alphas. Does it give you the location? I have already applied some alignment cleanups to the current cvs tree. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
When I sat down to send out Uncle G.'s patches to the debian
developers I realized that the patches really only apply to a moving
target. What I mean, is that they will only apply to current snapshots
(i.e. Jun 23's), but not to the older 6.5.1 release. By giving out these
patches, and telling them to just go and get a snapshot, they might end up
getting the snapshot on a day that pgsql is broken, or the patch will no
longer apply. The best solution I can think of is just to take one of the
snapshots (today's if it works, testing it now, otherwise last Fridays),
and setting it aside along with the patches in a seperate 'linux_alpha'
directory so packagers can have something "non-moving" to package for
thier distributions. Is this a good idea, or does someone have a better
one?
Also, I found at least a temporary solution to the problem of
alpha CPUs being detected as alphaev5, etc... and breaking the 'alpha'
makefile conditionals. Just add 'CPU:alpha' to the linux_alpha template.
Is there a reason that this would be a bad idea? I don't even really see
the reason why config.guess wants to differeniate between different alpha
CPUs in the first place?
----------------------------------------------------------------------------
| "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/ |
----------------------------------------------------------------------------
> > When I sat down to send out Uncle G.'s patches to the debian > developers I realized that the patches really only apply to a moving > target. What I mean, is that they will only apply to current snapshots > (i.e. Jun 23's), but not to the older 6.5.1 release. By giving out these > patches, and telling them to just go and get a snapshot, they might end up > getting the snapshot on a day that pgsql is broken, or the patch will no > longer apply. The best solution I can think of is just to take one of the > snapshots (today's if it works, testing it now, otherwise last Fridays), > and setting it aside along with the patches in a seperate 'linux_alpha' > directory so packagers can have something "non-moving" to package for > thier distributions. Is this a good idea, or does someone have a better > one? I would try applying to 6.5.1, make any hand tweeks needed, and generate a patch from that for 6.5.1. > Also, I found at least a temporary solution to the problem of > alpha CPUs being detected as alphaev5, etc... and breaking the 'alpha' > makefile conditionals. Just add 'CPU:alpha' to the linux_alpha template. > Is there a reason that this would be a bad idea? I don't even really see > the reason why config.guess wants to differeniate between different alpha > CPUs in the first place? Some optmizations are turned off in some Makefiles like backend/utils/adt and backend/storage/ipc. Now that I think of it, you can't send out patches for 6.5.1 because we don't have the alpha stuff in there that was put in after 6.5.1. I think the current snapshot may be safe for general use. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> When I sat down to send out Uncle G.'s patches to the debian
> developers I realized that the patches really only apply to a moving
> target. What I mean, is that they will only apply to current snapshots
> (i.e. Jun 23's), but not to the older 6.5.1 release. By giving out these
> patches, and telling them to just go and get a snapshot, they might end up
> getting the snapshot on a day that pgsql is broken, or the patch will no
> longer apply. The best solution I can think of is just to take one of the
> snapshots (today's if it works, testing it now, otherwise last Fridays),
> and setting it aside along with the patches in a seperate 'linux_alpha'
> directory so packagers can have something "non-moving" to package for
> thier distributions. Is this a good idea, or does someone have a better
> one?
I didn't realize that they weren't developed on v6.5.1 sources. That
is what I'll need to develop RPM patches. I'd suggest that we work
with the v6.5.1 tar file, unless we think that using this version is
unrealistic, in which case we are waiting for v6.6. As you point out,
a daily snapshot of almost any vintage should be suspect.
Lamar Owen is talking to RedHat about getting access to an Alpha
machine to help with RPM builds. If that pans out perhaps it will be a
good resource for us...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
On Thu, 29 Jul 1999, Bruce Momjian wrote:
> > Also, I found at least a temporary solution to the problem of
> > alpha CPUs being detected as alphaev5, etc... and breaking the 'alpha'
> > makefile conditionals. Just add 'CPU:alpha' to the linux_alpha template.
> > Is there a reason that this would be a bad idea? I don't even really see
> > the reason why config.guess wants to differeniate between different alpha
> > CPUs in the first place?
>
> Some optmizations are turned off in some Makefiles like
> backend/utils/adt and backend/storage/ipc.
From what I can tell (i.e. via grep), the CPU variable is only
used to turn on/off the linux/alpha specific makefile rules that have been
added recently. Now, in the future that might change, and there be
optimizations only for a certain level of alpha chip, which the templates
hack could break. Of course, we could just deal with the problem when we
reach it, since it will not be difficult to undo the templates hack and
come up with another way to detect CPU type at the makefile level.
> Now that I think of it, you can't send out patches for 6.5.1 because
> we don't have the alpha stuff in there that was put in after 6.5.1.
> I think the current snapshot may be safe for general use.
That is what I figured out when the diff between 6.5.1 and
Friday's snapshot came out at about 3.5MB. The time required to backport
the linux/alpha patches to 6.5.1 would be better spent else where.
I just grabbed today's snapshot, patches applied fined, compiled
and ran regression tests with no problems. Also, the regression tests only
generated 20 unaliagned traps this time, which is a reduction from earlier
(I think).
As for distribution packages, we want to get pgsql packages for
alpha with these patches out there so people can pound on them before we
roll the patches into the cvs tree for a formal release. That way,
anything still lingering would be found soon, rather than later. Of
course, we would want the packages to say clearly that they are beta or
preliminary version only, and so don't use for mission critical operations
until one has tested it out.
Anyway, I will make a set of patches on today's snapshot that
includes Uncle G's, and clean up of the linux_alpha template file (setting
-O2 again, and the CPU define), and then post that here to be forwarded on
to package developers by the respective people (I will get them to the
debian people). Also, either a copy of today's snapshot needs to be set
aside (on the ftp site) for applying these patches, or I will stick the
snapshot on my web site.
TTYL.
----------------------------------------------------------------------------
| "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/ |
----------------------------------------------------------------------------
> > Now that I think of it, you can't send out patches for 6.5.1 because
> > we don't have the alpha stuff in there that was put in after 6.5.1.
> > I think the current snapshot may be safe for general use.
> That is what I figured out when the diff between 6.5.1 and
> Friday's snapshot came out at about 3.5MB. The time required to backport
> the linux/alpha patches to 6.5.1 would be better spent else where.
> As for distribution packages, we want to get pgsql packages for
> alpha with these patches out there so people can pound on them before we
> roll the patches into the cvs tree for a formal release. That way,
> anything still lingering would be found soon, rather than later. Of
> course, we would want the packages to say clearly that they are beta or
> preliminary version only, and so don't use for mission critical operations
> until one has tested it out.
I'm disappointed that we won't have a set of patches for v6.5.1. Is
there any possibility of putting these patches into our REL6_5_PATCHES
branch to prepare for a v6.5.2 release? What in the current set of
patches would make this difficult? I believe that Tom Lane has been
pretty good about committing to that branch, and I don't know what
else might be missing.
I'm willing to try patching that branch if others could help with
testing (don't have an Alpha myself).
I've been trying to get things together so we can have a viable RPM
distribution of Postgres for Alphas. RedHat is interested, and I think
that it would help the Postgres cause. Does anyone else have this
specific interest, or should we just have them wait another 4 months??
Comments or suggestions?
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
> > > Now that I think of it, you can't send out patches for 6.5.1 because > > > we don't have the alpha stuff in there that was put in after 6.5.1. > > > I think the current snapshot may be safe for general use. > > That is what I figured out when the diff between 6.5.1 and > > Friday's snapshot came out at about 3.5MB. The time required to backport > > the linux/alpha patches to 6.5.1 would be better spent else where. > > As for distribution packages, we want to get pgsql packages for > > alpha with these patches out there so people can pound on them before we > > roll the patches into the cvs tree for a formal release. That way, > > anything still lingering would be found soon, rather than later. Of > > course, we would want the packages to say clearly that they are beta or > > preliminary version only, and so don't use for mission critical operations > > until one has tested it out. > > I'm disappointed that we won't have a set of patches for v6.5.1. Is > there any possibility of putting these patches into our REL6_5_PATCHES > branch to prepare for a v6.5.2 release? What in the current set of > patches would make this difficult? I believe that Tom Lane has been > pretty good about committing to that branch, and I don't know what > else might be missing. OK, I don't want Thomas disappointed. We have the changes for alignment I made, and some changes for optimization in certain places, and the Uncle George patch, and the removal of the bad comment in the template file. My recommendation(hold on to your seats) is to take the current cvs tree, patch it with Uncle George's patches and any others needed, and release a 6.5.2 release that addresses alpha. We can back-patch 6.5.2, but there is really no reason to do that. There is really nothing 'special' in the current tree. In fact, the most risky of them are the alpha ones, and since that is what we are trying to fix, we are not adding any new problems to the code. I am working on some cache stuff, but that is not committed. > I've been trying to get things together so we can have a viable RPM > distribution of Postgres for Alphas. RedHat is interested, and I think > that it would help the Postgres cause. Does anyone else have this > specific interest, or should we just have them wait another 4 months?? That is a long time. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> OK, I don't want Thomas disappointed.
Thanks. I think ;)
> We have the changes for alignment
> I made, and some changes for optimization in certain places, and the
> Uncle George patch, and the removal of the bad comment in the template
> file.
> My recommendation(hold on to your seats) is to take the current cvs
> tree, patch it with Uncle George's patches and any others needed, and
> release a 6.5.2 release that addresses alpha. We can back-patch 6.5.2,
> but there is really no reason to do that. There is really nothing
> 'special' in the current tree. In fact, the most risky of them are the
> alpha ones, and since that is what we are trying to fix, we are not
> adding any new problems to the code.
OK. Another tack would be to do what you suggest on the main tree, and
then backpatch using diffs on the entire tree. Then we can release on
the v6.5.x branch as we would have liked.
I'll be happy to attempt the backpatching, and if I fail then we can
proceed with a v6.5.2 release based on the main tree. But I'm more
comfortable knowing that we've inspected every patch, and included
only those which address something significant.
Does this sound unrealistic? I'm guessing that the backpatching can
happen fairly easily, but I don't understand why someone just reported
3.5MB of diffs. Hmm, how much of those diffs are on the docs tree? I
did make a bunch of changes to get the man pages going, and they
aren't relevant for v6.5.2 which could be limited to the src/ tree.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
> OK. Another tack would be to do what you suggest on the main tree, and > then backpatch using diffs on the entire tree. Then we can release on > the v6.5.x branch as we would have liked. Why not just use the current tree. What does backpatching the entire tree do for us? > > I'll be happy to attempt the backpatching, and if I fail then we can > proceed with a v6.5.2 release based on the main tree. But I'm more > comfortable knowing that we've inspected every patch, and included > only those which address something significant. Oh, yes. I see. Good idea to just review the patches and see what is involved. It is actually pretty easy to do that in one big patch. > Does this sound unrealistic? I'm guessing that the backpatching can > happen fairly easily, but I don't understand why someone just reported > 3.5MB of diffs. Hmm, how much of those diffs are on the docs tree? I > did make a bunch of changes to get the man pages going, and they > aren't relevant for v6.5.2 which could be limited to the src/ tree. Don't know. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Thu, 29 Jul 1999, Bruce Momjian wrote:
> > I'm disappointed that we won't have a set of patches for v6.5.1. Is
> > there any possibility of putting these patches into our REL6_5_PATCHES
> > branch to prepare for a v6.5.2 release? What in the current set of
> > patches would make this difficult? I believe that Tom Lane has been
> > pretty good about committing to that branch, and I don't know what
> > else might be missing.
>
> OK, I don't want Thomas disappointed. We have the changes for alignment
> I made, and some changes for optimization in certain places, and the
> Uncle George patch, and the removal of the bad comment in the template
> file.
Attached is a mini patch of the changes I made to the linux_alpha
template file. Review and use as you wish. Basically just sets -O2 flag
for CFLAGS and also forces the CPU variable to be alpha, so as not to
break the alpha specific makefile rules when the alpha processor is
get detected as an alphaev5, etc...
Otherwise, everything looks good!
> My recommendation(hold on to your seats) is to take the current cvs
> tree, patch it with Uncle George's patches and any others needed, and
> release a 6.5.2 release that addresses alpha. We can back-patch 6.5.2,
> but there is really no reason to do that. There is really nothing
> 'special' in the current tree. In fact, the most risky of them are the
> alpha ones, and since that is what we are trying to fix, we are not
> adding any new problems to the code.
While my opinion might not matter that much (not being a major
pgsql developer), I second this idea! By the end of the day I will have
taken the 'alpha' patched version of today's snapshot, and
compiled/regressed on Linux/Intel, Solaris/Sparc, and maybe Linux/Sparc.
That should give us a good idea if the alpha patches are going to break
anything on other platforms (hopefully not).
Once you have a 6.5.2 release source tree ready for download (i.e.
just before public announcement/distribution), let me know and I will run
it through my systems (Alpha, Intel, and Sparc) just to double check.
Worst case, Linux/Alpha uses 6.5.2 and everyone else (other
platforms) uses 6.5.1 until the next major release. This, while a bit
confusing/annoying, would not be a show stopper. :)
> > I've been trying to get things together so we can have a viable RPM
> > distribution of Postgres for Alphas. RedHat is interested, and I think
> > that it would help the Postgres cause. Does anyone else have this
> > specific interest, or should we just have them wait another 4 months??
>
> That is a long time.
Hence the reason we should try and get an easy to
use/compile/package version of pgsql for Linux/Alpha out the door as soon
as reasonably possible. That is, one with out patches, it just compiles
out of the box (for Linux/Alpha) at leat.
TTYL.
----------------------------------------------------------------------------
| "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/ |
----------------------------------------------------------------------------
Вложения
> Attached is a mini patch of the changes I made to the linux_alpha > template file. Review and use as you wish. Basically just sets -O2 flag > for CFLAGS and also forces the CPU variable to be alpha, so as not to > break the alpha specific makefile rules when the alpha processor is > get detected as an alphaev5, etc... > Otherwise, everything looks good! I question the CPU line. I modified configure to set CPU. Does the template over-ride this? -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Thu, 29 Jul 1999, Thomas Lockhart wrote:
> OK. Another tack would be to do what you suggest on the main tree, and
> then backpatch using diffs on the entire tree. Then we can release on
> the v6.5.x branch as we would have liked.
>
> I'll be happy to attempt the backpatching, and if I fail then we can
> proceed with a v6.5.2 release based on the main tree. But I'm more
> comfortable knowing that we've inspected every patch, and included
> only those which address something significant.
I will leave you guys to the finer points of source tree
management (still learning all of the capablities of cvs myself).
> Does this sound unrealistic? I'm guessing that the backpatching can
> happen fairly easily, but I don't understand why someone just reported
> 3.5MB of diffs. Hmm, how much of those diffs are on the docs tree? I
> did make a bunch of changes to get the man pages going, and they
> aren't relevant for v6.5.2 which could be limited to the src/ tree.
I was the one who reported the 3.5MB of diffs. And yes, I did
check to see how many of them were docs, only about 20% of the total
diffs. :( I simply took an alpha patched snapshot from today and diffed it
against the 6.5.1 release (after removing all of the CVS directories from
the latter).
I still think that backpatching to create an "alpha" patch for
6.5.1 is a bad idea and a waste of time. It is also a waste of time for
distribution packagers who have deal with applying yet another patch to
the distribution source tree, and everything involved with that. Also,
there are those who just want to get the source and compile pgsql for
thier own use themselves, and many of them don't like having to mess with
patches. Overall, it just adds unnecessary work and complexity to the
release of a "Linux/Alpha Ready" version of pgsql.
IMHO a 6.5.2 release with all of the necessary alpha patches
already in the distribution source tree is a much cleaner, clearer
solution, for distribution packagers, average users, and
compile-it-yourself-people.
My two cents. TTYL.
----------------------------------------------------------------------------
| "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/ |
----------------------------------------------------------------------------
> IMHO a 6.5.2 release with all of the necessary alpha patches > already in the distribution source tree is a much cleaner, clearer > solution, for distribution packagers, average users, and > compile-it-yourself-people. I think he was going to generate a 6.5.2 by back-patching, not distributing a new patch to make 6.5.2. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> > IMHO a 6.5.2 release with all of the necessary alpha patches
> > already in the distribution source tree is a much cleaner, clearer
> > solution, for distribution packagers, average users, and
> > compile-it-yourself-people.
> I think he was going to generate a 6.5.2 by back-patching, not
> distributing a new patch to make 6.5.2.
Yup.
OK, I'm trying to do this to help the Alpha folks, in such a way that
it helps the Alpha-linux-RH folks to get RPMs also. Having a 6.5.2
which does not run on Intel or Sparc does not help. Having a 6.5.2
which has diverged from the 6.5.x tree in unknown ways does not help.
Having us decide by consensus the appropriate model for s/w
development (main tree with changes progressing to a full release,
branch tree to carry maintenance changes) and then at the first
opportunity step away from that seems counterproductive in the
extreme. We ran into this same discussion during v6.4.x, and we're
doing it again.
If y'all can't maintain two branches, then let's stop doing it. otoh,
we can't do maintenance releases without a stable branch, so we'd
better think about it before giving up.
I've offered to help, much more than I should bother with. I'll leave
it to other Alpha stakeholders to decide what they want. I should
point out that I offered to our RedHat contacts to try to marshall an
Alpha-ready build, but so far it's like herding cats.
And *really*, if we have 3.5MB of diffs, who are we kidding about
knowing where they all came from and what they are doing? Backpatching
or developing patches on a clean 6.5.1 release is the only thing to do
for a 6.5.2. Otherwise, call it 6.6-prealpha and we'll wait 4 months
for RPMs.
My $0.03 ;)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
> And *really*, if we have 3.5MB of diffs, who are we kidding about > knowing where they all came from and what they are doing? Backpatching > or developing patches on a clean 6.5.1 release is the only thing to do > for a 6.5.2. Otherwise, call it 6.6-prealpha and we'll wait 4 months > for RPMs. OK, let's punt. If someone wants to develop an alpha-only patch for 6.5.1, they are welcome. We certainly had enought beta time to allow Alpha people to address this. After the final minor release is just too late. Sorry. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> OK, I'm trying to do this to help the Alpha folks, in such a way that > it helps the Alpha-linux-RH folks to get RPMs also. Having a 6.5.2 [snip] > point out that I offered to our RedHat contacts to try to marshall an > Alpha-ready build, but so far it's like herding cats. > And *really*, if we have 3.5MB of diffs, who are we kidding about > knowing where they all came from and what they are doing? Backpatching > or developing patches on a clean 6.5.1 release is the only thing to do > for a 6.5.2. Otherwise, call it 6.6-prealpha and we'll wait 4 months > for RPMs. > My $0.03 ;) I second this. In the last few months, PostgreSQL has really been making progress in the mindshare area -- once, what was written off as being unreliable, buggy, and slow, not to mention feature-lean, is now being touted by many as "commercial quality", "the Free Software equivalent to Oracle", "stable", "reliable", and "fast". I'm all for having the latest and greatest snapshots working on the Alpha -- Woo Hoo, etc, etc. I'm all for the current CVS tree building like a champ on Alpha -- this is good stuff. HOWEVER, if there is a need for a 6.5.x running on Alpha, then 6.5.1 needs to get the Alpha patches (possibly a few other reliability patches -- but, keep the number of patches down to a minimum -- this is still a 6.5.x release -- bug fixing only.) for a 6.5.2, where the advertised bugfixes include the long-awaited Alpha patches. For goodness sakes, Alpha is a major architecture -- this needs to be done right. Make the number of possible variables a minimum -- let's get a patch set working that applies to virgin 6.5.1. If backporting and backpatching is required to do this, in the name of ROBUSTNESS -- by all means -- let's do it. (I say all this after Thomas had to "slap me around" a little -- I have been getting the cart before the horse on some of the RPM issues, and needed a good reminder of just what kind of software package I'm working on! This is an RDBMS -- people will be using this for major data -- like the guy from Australia who e-mailed here not long ago about 6.5 vs 6.4.2, and mentioned that his database had a few MILLION rows -- did anybody catch the significance of that? (Wayne Pierkarski from senet.com.au) Thanks for the wakeup call, Thomas.) Thanks and kudos go the the guys who have made the Alpha port work -- now, let's get a patch set against 6.5.1 that works -- if that proves too difficult, we'll just have to wait until pre-6.6, as Thomas already said. PostgreSQL is kicking major tuples -- let's keep it that way.... My 1.5 cents... Lamar Owen WGCR Internet Radio
Okay, let me get this straight...v6.5 was in beta for, what, 2 months?
And it isn't until *after* v6.5.1 is released that the Alpha guys realized
that "oops, it doesn't work"? And they have a patch that amounts to ~1/2
the size of the current distribution to get this to work?
*rofl*
The stable branch is meant to allow *minor* changes to go into it, and, if
there are enough, to generate a new *stable* distribution. Minor changes
are "we put && instead of || in an if statement that only shows up #ifdef
<feature> is enabled"...or even where a bug is fixed that is based on us
missing an error check that adds a few lines of code.
I have no problems with building a v6.5.2, or .3, or .4, if required...but
a 3.5MB diff does not constitute a 'minor bug fix' and should be merged
into v6.6 only...
On Fri, 30 Jul 1999, Thomas Lockhart wrote:
> > > IMHO a 6.5.2 release with all of the necessary alpha patches
> > > already in the distribution source tree is a much cleaner, clearer
> > > solution, for distribution packagers, average users, and
> > > compile-it-yourself-people.
> > I think he was going to generate a 6.5.2 by back-patching, not
> > distributing a new patch to make 6.5.2.
>
> Yup.
>
> OK, I'm trying to do this to help the Alpha folks, in such a way that
> it helps the Alpha-linux-RH folks to get RPMs also. Having a 6.5.2
> which does not run on Intel or Sparc does not help. Having a 6.5.2
> which has diverged from the 6.5.x tree in unknown ways does not help.
> Having us decide by consensus the appropriate model for s/w
> development (main tree with changes progressing to a full release,
> branch tree to carry maintenance changes) and then at the first
> opportunity step away from that seems counterproductive in the
> extreme. We ran into this same discussion during v6.4.x, and we're
> doing it again.
>
> If y'all can't maintain two branches, then let's stop doing it. otoh,
> we can't do maintenance releases without a stable branch, so we'd
> better think about it before giving up.
>
> I've offered to help, much more than I should bother with. I'll leave
> it to other Alpha stakeholders to decide what they want. I should
> point out that I offered to our RedHat contacts to try to marshall an
> Alpha-ready build, but so far it's like herding cats.
>
> And *really*, if we have 3.5MB of diffs, who are we kidding about
> knowing where they all came from and what they are doing? Backpatching
> or developing patches on a clean 6.5.1 release is the only thing to do
> for a 6.5.2. Otherwise, call it 6.6-prealpha and we'll wait 4 months
> for RPMs.
>
> My $0.03 ;)
>
> - Thomas
>
> --
> Thomas Lockhart lockhart@alumni.caltech.edu
> South Pasadena, California
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Thu, 29 Jul 1999, Bruce Momjian wrote:
> > IMHO a 6.5.2 release with all of the necessary alpha patches
> > already in the distribution source tree is a much cleaner, clearer
> > solution, for distribution packagers, average users, and
> > compile-it-yourself-people.
>
> I think he was going to generate a 6.5.2 by back-patching, not
> distributing a new patch to make 6.5.2.
Excuse ignorance...but...what is back-patching? :(
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> On Thu, 29 Jul 1999, Bruce Momjian wrote: > > > > IMHO a 6.5.2 release with all of the necessary alpha patches > > > already in the distribution source tree is a much cleaner, clearer > > > solution, for distribution packagers, average users, and > > > compile-it-yourself-people. > > > > I think he was going to generate a 6.5.2 by back-patching, not > > distributing a new patch to make 6.5.2. > > Excuse ignorance...but...what is back-patching? :( Diff'ing stable and current trees, reviewing all the changes, and applying the patch to make the stable tree look similar to the current tree, without any possible bugs. At this point, we are saying goodbye to 6.5.*. Alpha people can generate an alpha-only patch for 6.5.1 if they wish. They are too late for the 6.5.* tree. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Wed, 28 Jul 1999, Bruce Momjian wrote:
> > On Wed, 28 Jul 1999, Thomas Lockhart wrote:
> >
> > > > This time it worked great! No stuck spinlocks (and -O2 was used!),
> > > > and all the regression tests, saved for rules as Uncle G. has already
> > > > mentioned.
> > >
> > > Fantastic.
> >
> > One thing I did forget to mention, is that I am getting a decent
> > handful of unaligned traps from postmaster. To put a number on that, from
> > running the regression tests three times, once with numeric_big enabled, I
> > got ~164 unaligned traps.
> > Not a show stopper, but something that probably needs to looked
> > into at some point in order to maximize performance of pgsql on Alphas.
>
> Does it give you the location? I have already applied some alignment
> cleanups to the current cvs tree.
The only location it gives are memory addresses, like:
postmaster(21349): unaligned trap at 0000000120131600: 000000011fff6a5d 28 1
If these are useful (which I doubt), I can provide you with a set from the
run of the regression tests quite easily.
----------------------------------------------------------------------------
| "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/ |
----------------------------------------------------------------------------
On Thu, 29 Jul 1999, Bruce Momjian wrote:
> > Attached is a mini patch of the changes I made to the linux_alpha
> > template file. Review and use as you wish. Basically just sets -O2 flag
> > for CFLAGS and also forces the CPU variable to be alpha, so as not to
> > break the alpha specific makefile rules when the alpha processor is
> > get detected as an alphaev5, etc...
> > Otherwise, everything looks good!
>
> I question the CPU line. I modified configure to set CPU. Does the
> template over-ride this?
Apparently yes, the template definitions override anything that
configure figures out. I didn't know which method would be better,
modifying config.guess to return 'alpha' for CPU no matter what was
exactly was detected (as long as it was still an alpha of some sort) or
force CPU to be 'alpha' in templates. Your choice which way to do it, just
make sure CPU is alpha no matter if it is a UDB (21064), XLT (21164), or
DS20 (21264) that one is compling on.
----------------------------------------------------------------------------
| "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/ |
----------------------------------------------------------------------------
> > Does it give you the location? I have already applied some alignment > > cleanups to the current cvs tree. > > The only location it gives are memory addresses, like: > > postmaster(21349): unaligned trap at 0000000120131600: 000000011fff6a5d 28 1 > > If these are useful (which I doubt), I can provide you with a set from the > run of the regression tests quite easily. Oh. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> > I question the CPU line. I modified configure to set CPU. Does the > > template over-ride this? > > Apparently yes, the template definitions override anything that > configure figures out. I didn't know which method would be better, > modifying config.guess to return 'alpha' for CPU no matter what was > exactly was detected (as long as it was still an alpha of some sort) or > force CPU to be 'alpha' in templates. Your choice which way to do it, just > make sure CPU is alpha no matter if it is a UDB (21064), XLT (21164), or > DS20 (21264) that one is compling on. I guess template is OK. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Fri, 30 Jul 1999, Thomas Lockhart wrote:
> > > IMHO a 6.5.2 release with all of the necessary alpha patches
> > > already in the distribution source tree is a much cleaner, clearer
> > > solution, for distribution packagers, average users, and
> > > compile-it-yourself-people.
> > I think he was going to generate a 6.5.2 by back-patching, not
> > distributing a new patch to make 6.5.2.
Ok, you lost me on the terminology there then. What exactly is
'back-patching'?
> If y'all can't maintain two branches, then let's stop doing it. otoh,
> we can't do maintenance releases without a stable branch, so we'd
> better think about it before giving up.
I do follow your logic on a stable vs. unstable tree, and can see
the benefit of having it.
> I've offered to help, much more than I should bother with. I'll leave
> it to other Alpha stakeholders to decide what they want. I should
> point out that I offered to our RedHat contacts to try to marshall an
> Alpha-ready build, but so far it's like herding cats.
Yea, it has been like that with the Linux/Alpha port for some
time, including other packages then pgsql alone. :( As for the other Alpha
stakeholders, I have yet to hear from any of them at all in this
disscussion and for a while in any discussion concerning pgsql and
Linux/Alpha. Of course, every now and then, some Linux/Alpha user comes
along and asks why we haven't moved anywhere with pgsql in the last so
long, and gets mad with any answer I try and give them. My conclusion
about Linux/Alpha is that lots of people want the power of the alpha
processor, but don't want to help out and get rid of some of the lingering
sharp edges. They want it to work right out of the box! That leaves things
to a few of us die hards to get everything working, and most of them
focus on more fundamental things, like gcc and glibc, and the applications
end up getting the short end of the stick. Ok, I will get off my soap box
here, back to the trenches....
> And *really*, if we have 3.5MB of diffs, who are we kidding about
> knowing where they all came from and what they are doing? Backpatching
> or developing patches on a clean 6.5.1 release is the only thing to do
> for a 6.5.2. Otherwise, call it 6.6-prealpha and we'll wait 4 months
> for RPMs.
After this discussion and a few tests of my own, I think I had
better change my position on this issue.
First of all, today's snapshot with Uncle G's patches compiles and
runs on Linux/Intel and Solaris/Sparc as well as they do without the
patches on the same snapshot for the most part. Though the patches seem to
break the random regression test on Linux/Intel. Also, today's snapshot
(clean) will not compile on Solaris/Sparc, as there is an extra #endif in
./src/backend/port/isinf.c that gcc on Solaris pukes on. :(
So, this snapshot is in suspect, and it looks like the alpha
patches are as well, at least as far as other platforms go.
My vote would be go back and do a 'alpha' patch off of 6.5.1, and
distribute that to the distribution people to get pgsql running on
Linux/Alpha in the short time. Then, four months or so down the road when
the next release target comes up, we plan to have a version of pgsql that
will run on both Alpha and other platforms. That means Uncle G's patches
need to be checked for what they do to the other platforms.
This would get us a Alpha ready version of pgsql now (there has
been enough delay as it is, we really don't want to wait any more), not
put us out on the limb with a possibly unstable release of pgsql, and
gives us time to get the alpha patches properly tested and integrated into
the main source tree.
As I see it, these are the following things that need to be added
to 6.5.1 to make it alpha ready:
* Uncle G's Alpha patches { which I have }.
* Makefile conditionals for Linux/Alpha { which I can find with
only moderate trouble }.
* Bruce's alignment patches { which I do not have }.
Bruce, if you could get me your alignment patches, then I will try and
apply the above to 6.5.1, and make a patch that bring 6.5.1 up to alpha
ready state. Then we give that patch to debian and RH developers, tell
them to only apply it to thier alpha builds, and that we will have a
universal source tree for all platforms (including alpha) in a few months.
This is simular to what was done (might even still be done) for
the Linux kernel itself. To compile a 2.0.x kernel for Linux/Alpha, one
got the clean source, a set of alpha patches for the same rev level, and
applied them to the clean source to generate an alpha ready kernel source
tree.
Is this a viable idea, or just another horrible kludge?
> My $0.03 ;)
Raising the ante here? :) Well, then this was my four cents!
----------------------------------------------------------------------------
| "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/ |
----------------------------------------------------------------------------
On Thu, 29 Jul 1999, The Hermit Hacker wrote:
> Okay, let me get this straight...v6.5 was in beta for, what, 2 months?
> And it isn't until *after* v6.5.1 is released that the Alpha guys realized
> that "oops, it doesn't work"? And they have a patch that amounts to ~1/2
> the size of the current distribution to get this to work?
>
> *rofl*
Yea, I think it has turned into a bit of a crazy mess. :) I had
meant to do something about Alpha for the 6.5 release, but it came too
soon after school got out to do anything (i.e. when I actually had free
time). Then Uncle G. came along, out of the blue, and fixed everything in
a few days, but then got impatient that we had not applied his patches
after a few more days and then moved on to other conquests. That left us
with patches that worked, which we were grateful for (at least I was), but
provided unknown affects on other platforms and only against an unstable,
in flux snapshot.
Then I tried to see how many differences there were between 6.5.1
and the current snapshot, only to find that the differences were "a lot".
> The stable branch is meant to allow *minor* changes to go into it, and, if
> there are enough, to generate a new *stable* distribution. Minor changes
> are "we put && instead of || in an if statement that only shows up #ifdef
> <feature> is enabled"...or even where a bug is fixed that is based on us
> missing an error check that adds a few lines of code.
Agreed. Uncle G's alpha patches alone break that as they are 62k
in size and touch quite a few files.
> I have no problems with building a v6.5.2, or .3, or .4, if required...but
> a 3.5MB diff does not constitute a 'minor bug fix' and should be merged
> into v6.6 only...
Yea, 3.5MB does not consitute a minor bug fix (maybe for M$ it
does, but lets not go there). And that includes all changes between 6.5.1
and the current snapshot, not just the alpha ones.
So, after reading the emails that arrived while writing my last
one... If I could get my hands on Bruce's alignment patches, then by
Monday, I should be able to have a set of alpha patches against 6.5.1 that
provide a working alpha version for the time being (until 6.6 comes around
and we can clean up the alpha patches and put them in the main tree).
PS. As far as I can tell, us Alpha guys are pretty few in number,
at least those who are actually subscribed to the pgsql-ports and
pgsql-hackers email lists and try and do something for pgsql on
Linux/Alpha. Unfortuntely this "Alpha guy" often finds himself very busy
and his C skills not up to the task of hunting down obscure platform bugs
in a huge mass of code. Something along the lines of "The spirit is
willing, but the flesh is weak." :(
----------------------------------------------------------------------------
| "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 do not want to see any patches commit'd to v6.5.x branch that is
*anything* but a minor bug fix...personally, we had a 2 month beta period
on this...the Alpha related stuff should have been submit'd then, at the
very latest...
Please feel free to work at getting these into v6.6, *before* v6.6 is
released, so that this problem doesn't rear its head again...
On Thu, 29 Jul 1999, Ryan Kirkpatrick wrote:
> On Fri, 30 Jul 1999, Thomas Lockhart wrote:
>
> > > > IMHO a 6.5.2 release with all of the necessary alpha patches
> > > > already in the distribution source tree is a much cleaner, clearer
> > > > solution, for distribution packagers, average users, and
> > > > compile-it-yourself-people.
> > > I think he was going to generate a 6.5.2 by back-patching, not
> > > distributing a new patch to make 6.5.2.
>
> Ok, you lost me on the terminology there then. What exactly is
> 'back-patching'?
>
> > If y'all can't maintain two branches, then let's stop doing it. otoh,
> > we can't do maintenance releases without a stable branch, so we'd
> > better think about it before giving up.
>
> I do follow your logic on a stable vs. unstable tree, and can see
> the benefit of having it.
>
> > I've offered to help, much more than I should bother with. I'll leave
> > it to other Alpha stakeholders to decide what they want. I should
> > point out that I offered to our RedHat contacts to try to marshall an
> > Alpha-ready build, but so far it's like herding cats.
>
> Yea, it has been like that with the Linux/Alpha port for some
> time, including other packages then pgsql alone. :( As for the other Alpha
> stakeholders, I have yet to hear from any of them at all in this
> disscussion and for a while in any discussion concerning pgsql and
> Linux/Alpha. Of course, every now and then, some Linux/Alpha user comes
> along and asks why we haven't moved anywhere with pgsql in the last so
> long, and gets mad with any answer I try and give them. My conclusion
> about Linux/Alpha is that lots of people want the power of the alpha
> processor, but don't want to help out and get rid of some of the lingering
> sharp edges. They want it to work right out of the box! That leaves things
> to a few of us die hards to get everything working, and most of them
> focus on more fundamental things, like gcc and glibc, and the applications
> end up getting the short end of the stick. Ok, I will get off my soap box
> here, back to the trenches....
>
> > And *really*, if we have 3.5MB of diffs, who are we kidding about
> > knowing where they all came from and what they are doing? Backpatching
> > or developing patches on a clean 6.5.1 release is the only thing to do
> > for a 6.5.2. Otherwise, call it 6.6-prealpha and we'll wait 4 months
> > for RPMs.
>
> After this discussion and a few tests of my own, I think I had
> better change my position on this issue.
> First of all, today's snapshot with Uncle G's patches compiles and
> runs on Linux/Intel and Solaris/Sparc as well as they do without the
> patches on the same snapshot for the most part. Though the patches seem to
> break the random regression test on Linux/Intel. Also, today's snapshot
> (clean) will not compile on Solaris/Sparc, as there is an extra #endif in
> ./src/backend/port/isinf.c that gcc on Solaris pukes on. :(
> So, this snapshot is in suspect, and it looks like the alpha
> patches are as well, at least as far as other platforms go.
> My vote would be go back and do a 'alpha' patch off of 6.5.1, and
> distribute that to the distribution people to get pgsql running on
> Linux/Alpha in the short time. Then, four months or so down the road when
> the next release target comes up, we plan to have a version of pgsql that
> will run on both Alpha and other platforms. That means Uncle G's patches
> need to be checked for what they do to the other platforms.
> This would get us a Alpha ready version of pgsql now (there has
> been enough delay as it is, we really don't want to wait any more), not
> put us out on the limb with a possibly unstable release of pgsql, and
> gives us time to get the alpha patches properly tested and integrated into
> the main source tree.
> As I see it, these are the following things that need to be added
> to 6.5.1 to make it alpha ready:
>
> * Uncle G's Alpha patches { which I have }.
> * Makefile conditionals for Linux/Alpha { which I can find with
> only moderate trouble }.
> * Bruce's alignment patches { which I do not have }.
>
> Bruce, if you could get me your alignment patches, then I will try and
> apply the above to 6.5.1, and make a patch that bring 6.5.1 up to alpha
> ready state. Then we give that patch to debian and RH developers, tell
> them to only apply it to thier alpha builds, and that we will have a
> universal source tree for all platforms (including alpha) in a few months.
> This is simular to what was done (might even still be done) for
> the Linux kernel itself. To compile a 2.0.x kernel for Linux/Alpha, one
> got the clean source, a set of alpha patches for the same rev level, and
> applied them to the clean source to generate an alpha ready kernel source
> tree.
> Is this a viable idea, or just another horrible kludge?
>
> > My $0.03 ;)
>
> Raising the ante here? :) Well, then this was my four cents!
>
> ----------------------------------------------------------------------------
> | "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/ |
> ----------------------------------------------------------------------------
>
>
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> Yea, it has been like that with the Linux/Alpha port for some
> time, including other packages then pgsql alone. :( As for the other Alpha
> stakeholders, I have yet to hear from any of them at all in this
> disscussion and for a while in any discussion concerning pgsql and
> Linux/Alpha. Of course, every now and then, some Linux/Alpha user comes
> along and asks why we haven't moved anywhere with pgsql in the last so
> long, and gets mad with any answer I try and give them. My conclusion
> about Linux/Alpha is that lots of people want the power of the alpha
> processor, but don't want to help out and get rid of some of the lingering
> sharp edges. They want it to work right out of the box! That leaves things
> to a few of us die hards to get everything working, and most of them
> focus on more fundamental things, like gcc and glibc, and the applications
> end up getting the short end of the stick. Ok, I will get off my soap box
> here, back to the trenches....
Yes, this is our impression too. We get lots of head-shaking, but not
lots of roll-up-their sleves help.
> First of all, today's snapshot with Uncle G's patches compiles and
> runs on Linux/Intel and Solaris/Sparc as well as they do without the
> patches on the same snapshot for the most part. Though the patches seem to
> break the random regression test on Linux/Intel. Also, today's snapshot
> (clean) will not compile on Solaris/Sparc, as there is an extra #endif in
> ./src/backend/port/isinf.c that gcc on Solaris pukes on. :(
Fixed now. That was me. That file was a mess before.
> So, this snapshot is in suspect, and it looks like the alpha
> patches are as well, at least as far as other platforms go.
> My vote would be go back and do a 'alpha' patch off of 6.5.1, and
> distribute that to the distribution people to get pgsql running on
> Linux/Alpha in the short time. Then, four months or so down the road when
> the next release target comes up, we plan to have a version of pgsql that
> will run on both Alpha and other platforms. That means Uncle G's patches
> need to be checked for what they do to the other platforms.
Agreed.
> This would get us a Alpha ready version of pgsql now (there has
> been enough delay as it is, we really don't want to wait any more), not
> put us out on the limb with a possibly unstable release of pgsql, and
> gives us time to get the alpha patches properly tested and integrated into
> the main source tree.
> As I see it, these are the following things that need to be added
> to 6.5.1 to make it alpha ready:
>
> * Uncle G's Alpha patches { which I have }.
> * Makefile conditionals for Linux/Alpha { which I can find with
> only moderate trouble }.
> * Bruce's alignment patches { which I do not have }.
I just changed many DOUBLEALIGN's to MAXALIGN. It was a cosmetic fix,
as far as I could tell. Are they different on Alpha?
>
> Bruce, if you could get me your alignment patches, then I will try and
> apply the above to 6.5.1, and make a patch that bring 6.5.1 up to alpha
> ready state. Then we give that patch to debian and RH developers, tell
> them to only apply it to thier alpha builds, and that we will have a
> universal source tree for all platforms (including alpha) in a few months.
> This is simular to what was done (might even still be done) for
> the Linux kernel itself. To compile a 2.0.x kernel for Linux/Alpha, one
> got the clean source, a set of alpha patches for the same rev level, and
> applied them to the clean source to generate an alpha ready kernel source
> tree.
> Is this a viable idea, or just another horrible kludge?
Sounds good.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Thu, 29 Jul 1999, Bruce Momjian wrote:
> > * Uncle G's Alpha patches { which I have }.
> > * Makefile conditionals for Linux/Alpha { which I can find with
> > only moderate trouble }.
> > * Bruce's alignment patches { which I do not have }.
>
> I just changed many DOUBLEALIGN's to MAXALIGN. It was a cosmetic fix,
> as far as I could tell. Are they different on Alpha?
So, if I were to go through and make these changes in the -stable tree as
well, it would be purely cosmetic?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> On Thu, 29 Jul 1999, Bruce Momjian wrote:
>
> > > * Uncle G's Alpha patches { which I have }.
> > > * Makefile conditionals for Linux/Alpha { which I can find with
> > > only moderate trouble }.
> > > * Bruce's alignment patches { which I do not have }.
> >
> > I just changed many DOUBLEALIGN's to MAXALIGN. It was a cosmetic fix,
> > as far as I could tell. Are they different on Alpha?
>
> So, if I were to go through and make these changes in the -stable tree as
> well, it would be purely cosmetic?
>
I think so, but am not sure what the alpha has for those values.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> > As I see it, these are the following things that need to be added
> > to 6.5.1 to make it alpha ready:
> > * Uncle G's Alpha patches { which I have }.
> > * Makefile conditionals for Linux/Alpha
> > * Bruce's alignment patches { which I do not have }.
> I just changed many DOUBLEALIGN's to MAXALIGN. It was a cosmetic fix,
> as far as I could tell. Are they different on Alpha?
> > Bruce, if you could get me your alignment patches, then I will try and
> > apply the above to 6.5.1, and make a patch that bring 6.5.1 up to alpha
> > ready state.
I *love* this plan. And I'll go one better: v6.5.x is not "dead", in
the sense that Tom Lane has been faithfully applying relevant patches
for his fixes in case a v6.5.2 is released. I'll guess that the Intel
problems noted with the main tree are not present in the v6.5.x tree,
so any new problems noted would be due to the upcoming Alpha patches.
Let's develop patches on 6.5.x (I'll post snapshots when we want them)
and Lamar and I can test the Intel behavior.
Unless someone else wants to do it, I'll handle applying the Alpha
patches to the v6.5.x branch of CVS.
We can publish an Alpha candidate tree so the debian folks can look at
it, and we can build a RPM for someone (Uncle George?) to test on a
RedHat box.
v6.5.2 might be possible yet ;)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
On Fri, 30 Jul 1999, The Hermit Hacker wrote:
> I do not want to see any patches commit'd to v6.5.x branch that is
> *anything* but a minor bug fix...personally, we had a 2 month beta period
> on this...the Alpha related stuff should have been submit'd then, at the
> very latest...
Yea, they should have, but this is anything but a perfect world.
:(
> Please feel free to work at getting these into v6.6, *before* v6.6 is
> released, so that this problem doesn't rear its head again...
Will do! I will make an alpha patch for 6.5.1 to keep the alpha
people happy in the short term. Then I will work on evaluating the full
effect of the alpha patches and then integrate them into the main source
tree bit by bit until it all works on alpha, but does not adversly affect
any other platform. V6.6 is about four months out, right?
TTYL.
----------------------------------------------------------------------------
| "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/ |
----------------------------------------------------------------------------
On Fri, 30 Jul 1999, Bruce Momjian wrote:
> > On Thu, 29 Jul 1999, Bruce Momjian wrote:
> >
> > > > * Uncle G's Alpha patches { which I have }.
> > > > * Makefile conditionals for Linux/Alpha { which I can find with
> > > > only moderate trouble }.
> > > > * Bruce's alignment patches { which I do not have }.
> > >
> > > I just changed many DOUBLEALIGN's to MAXALIGN. It was a cosmetic fix,
> > > as far as I could tell. Are they different on Alpha?
> >
> > So, if I were to go through and make these changes in the -stable tree as
> > well, it would be purely cosmetic?
> >
>
> I think so, but am not sure what the alpha has for those values.
It is only cosmetic, for on the alpha, after configure is run,
ALIGNOF_{LONG,DOUBLE,ALIGNOF} all equal '8'. Further testing showed that
the macros LONGALIGN, DOBULEALIGN, and MAXALIGN generate the same result
when provided with the same input value. Therefore, I don't see anyway
that changing DOUBLEALIGNs to MAXALIGNs would reduce unaligned traps on
the alpha. :(
PS. I am testing an alpha patched 6.5.1 right now, and so far it
looks promising. :) Final results soon!
----------------------------------------------------------------------------
| "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/ |
----------------------------------------------------------------------------
On Thu, 29 Jul 1999, Bruce Momjian wrote:
> Yes, this is our impression too. We get lots of head-shaking, but not
> lots of roll-up-their sleves help.
That about sums things up very nicely... Even I am guilty of that
as I often find myself too busy to do anything more than tell someone that
pgsql is broken on alpha (not for much longer though), and yet never set
aside the time to do anything about it. :(
> > (clean) will not compile on Solaris/Sparc, as there is an extra #endif in
> > ./src/backend/port/isinf.c that gcc on Solaris pukes on. :(
>
> Fixed now. That was me. That file was a mess before.
Interesitng that neither Linux/Alpha or Linux/Intel puked on it...
> > Bruce, if you could get me your alignment patches, then I will try and
> > apply the above to 6.5.1, and make a patch that bring 6.5.1 up to alpha
> > ready state. Then we give that patch to debian and RH developers, tell
> > them to only apply it to thier alpha builds, and that we will have a
> > universal source tree for all platforms (including alpha) in a few months.
> > This is simular to what was done (might even still be done) for
> > the Linux kernel itself. To compile a 2.0.x kernel for Linux/Alpha, one
> > got the clean source, a set of alpha patches for the same rev level, and
> > applied them to the clean source to generate an alpha ready kernel source
> > tree.
> > Is this a viable idea, or just another horrible kludge?
>
> Sounds good.
Ok, I have already started hacking up 6.5.1. It will take a little
while to run the regression tests and then I want to run a few pgsql
applications of mine through it as well to pound on it further. If I can't
break it, then I will release a patch soon. :)
Are there any other "alpha hacks" that I missed? TTYL.
----------------------------------------------------------------------------
| "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/ |
----------------------------------------------------------------------------
On Fri, 30 Jul 1999, Thomas Lockhart wrote:
> > > As I see it, these are the following things that need to be added
> > > to 6.5.1 to make it alpha ready:
> > > * Uncle G's Alpha patches { which I have }.
> > > * Makefile conditionals for Linux/Alpha
> > > * Bruce's alignment patches { which I do not have }.
> > > Bruce, if you could get me your alignment patches, then I will try and
> > > apply the above to 6.5.1, and make a patch that bring 6.5.1 up to alpha
> > > ready state.
>
> I *love* this plan.
Great!
> And I'll go one better: v6.5.x is not "dead", in the sense that Tom
> Lane has been faithfully applying relevant patches for his fixes in
> case a v6.5.2 is released. I'll guess that the Intel problems noted
> with the main tree are not present in the v6.5.x tree, so any new
> problems noted would be due to the upcoming Alpha patches.
So, if I understand this correctly, the snapshot available on the
FTP site is from the unstable tree, and there is a "stable 6.5.x" tree
that can only be access by cvs{up}? And that this stable tree should not
have quite as much delta from 6.5.1 as the snapshots do? Or did I miss
something?
> Let's develop patches on 6.5.x (I'll post snapshots when we want them)
> and Lamar and I can test the Intel behavior.
Ok, patches are in progress. Regression tests passed, now pounding
on it with some of my own applications.
> We can publish an Alpha candidate tree so the debian folks can look at
> it, and we can build a RPM for someone (Uncle George?) to test on a
> RedHat box.
Sounds good.
> v6.5.2 might be possible yet ;)
Hmm... I don't think other people want to roll in the alpha
patches into the stable tree (with good reason). I think we are best off
with just an alpha only version of pgsql via patches on 6.5.1, and leave
integration of the alpha patches into the full pgsql source tree for 6.6.
My two cents.
----------------------------------------------------------------------------
| "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/ |
----------------------------------------------------------------------------
Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu> writes:
>>>> (clean) will not compile on Solaris/Sparc, as there is an extra #endif in
>>>> ./src/backend/port/isinf.c that gcc on Solaris pukes on. :(
>>
>> Fixed now. That was me. That file was a mess before.
> Interesitng that neither Linux/Alpha or Linux/Intel puked on it...
isinf.c doesn't get compiled at all on platforms that have native
isinf(), so the error wouldn't show up except on a platform that has
both a compiler that objects to extra #endif and no isinf().
I wouldn't be surprised if there are similar glitches in other files
under port/ :-(
> Ok, I have already started hacking up 6.5.1. It will take a little
> while to run the regression tests and then I want to run a few pgsql
> applications of mine through it as well to pound on it further. If I can't
> break it, then I will release a patch soon. :)
> Are there any other "alpha hacks" that I missed? TTYL.
You should be working from a CVS pull of the REL6_5_PATCHES branch,
not from the 6.5.1 distribution tarball --- I've committed several
fixes into that branch since 6.5.1, and I think other people have too.
(If that *is* what you're doing, then nevermind...)
regards, tom lane
> > Fixed now. That was me. That file was a mess before. > > Interesitng that neither Linux/Alpha or Linux/Intel puked on it... They probably don't use it. > Ok, I have already started hacking up 6.5.1. It will take a little > while to run the regression tests and then I want to run a few pgsql > applications of mine through it as well to pound on it further. If I can't > break it, then I will release a patch soon. :) > Are there any other "alpha hacks" that I missed? TTYL. No. The test for CPU in the Makefiles was so we could do -O2 in the general makefile, and just add some flags in the makefiles that caused problems. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> > And I'll go one better: v6.5.x is not "dead", in the sense that Tom
> > Lane has been faithfully applying relevant patches for his fixes in
> > case a v6.5.2 is released. I'll guess that the Intel problems noted
> > with the main tree are not present in the v6.5.x tree, so any new
> > problems noted would be due to the upcoming Alpha patches.
>
> So, if I understand this correctly, the snapshot available on the
> FTP site is from the unstable tree, and there is a "stable 6.5.x" tree
> that can only be access by cvs{up}? And that this stable tree should not
> have quite as much delta from 6.5.1 as the snapshots do? Or did I miss
> something?
Yes. This is correct.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Fri, 30 Jul 1999, Ryan Kirkpatrick wrote:
> So, if I understand this correctly, the snapshot available on the
> FTP site is from the unstable tree, and there is a "stable 6.5.x" tree
> that can only be access by cvs{up}? And that this stable tree should not
> have quite as much delta from 6.5.1 as the snapshots do? Or did I miss
> something?
this is correct...
> Hmm... I don't think other people want to roll in the alpha
> patches into the stable tree (with good reason). I think we are best off
> with just an alpha only version of pgsql via patches on 6.5.1, and leave
> integration of the alpha patches into the full pgsql source tree for 6.6.
> My two cents.
We are going to be rolling a v6.5.2, and .3, and .4 ... basically, until
v6.6 is released, v6.5.x is our stable release, and, from a commercial
perspective, has to be maintained.
I don't expect anyone working on -current to maintain it, I'm going to
work on it, but I do hope that if someone fixes a bug in -current that
exists in -stable, and that can be *easily* fixed, that we get the fix in
there also...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Fri, 30 Jul 1999, The Hermit Hacker wrote:
> On Fri, 30 Jul 1999, Ryan Kirkpatrick wrote:
> > Hmm... I don't think other people want to roll in the alpha
> > patches into the stable tree (with good reason). I think we are best off
> > with just an alpha only version of pgsql via patches on 6.5.1, and leave
> > integration of the alpha patches into the full pgsql source tree for 6.6.
> > My two cents.
>
> We are going to be rolling a v6.5.2, and .3, and .4 ... basically, until
> v6.6 is released, v6.5.x is our stable release, and, from a commercial
> perspective, has to be maintained.
I understand that. It is just that from what time I have spent
looking at the alpha patches, they do a lot more than just "maintenance".
So while there may indeed by 6.5.2, .3, etc.. releases, none of them
should include the alpha patches in the source tree (instead have a new
set of "after release" alpha specific patches, or stick them in contrib).
I don't want to put the alpha patches in until after I have a chance to
review them (for compatiblity to other platforms), which will probably
take a few weeks to a few months.
> I don't expect anyone working on -current to maintain it, I'm going to
> work on it, but I do hope that if someone fixes a bug in -current that
> exists in -stable, and that can be *easily* fixed, that we get the fix in
> there also...
Sounds good... Only the alpha fixes don't fall under the heading
of "*easily* fixed in -stable", so they ought to stay out of there for
now.
Otherwise your seperation of stable from current trees is a good
idea, and I now have a better understanding of development and release of
pgsql, especially in relation to the alpha patches. Thanks.
----------------------------------------------------------------------------
| "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/ |
----------------------------------------------------------------------------
On Fri, 30 Jul 1999, Tom Lane wrote:
> Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu> writes:
>
> > Ok, I have already started hacking up 6.5.1. It will take a little
> > while to run the regression tests and then I want to run a few pgsql
> > applications of mine through it as well to pound on it further. If I can't
> > break it, then I will release a patch soon. :)
> > Are there any other "alpha hacks" that I missed? TTYL.
>
> You should be working from a CVS pull of the REL6_5_PATCHES branch,
> not from the 6.5.1 distribution tarball --- I've committed several
> fixes into that branch since 6.5.1, and I think other people have too.
> (If that *is* what you're doing, then nevermind...)
Actually, I am working with the 6.5.1 tarball, for the simple
reason that I want a set of patches I can post on the debian-alpha mailing
list, along with the instructions to grab the 6.5.1 tarball from
ftp.postgresql.org, apply patches, configure, compile, install, and they
are set to go (No need to do a CVS pull, etc). Once this set of patches is
done and out, then I will do a cvs pull of the REL6_5_PATCHES branch and
make modifcations to my patch as needed so when 6.5.2 is released at some
later date, there is a minimal amount of work on my part to release new
alpha patches for that release.
That at least they easiest way I can see to do things for the near
term. For each 6.5.x release made, I make a set of patches that can be
applied to the release tar-ball, to make it alpha friendly. Then, only
when 6.6 comes along, will the alpha patches be intergrated into the main
tree, and the extra, "after-release-alpha-patches" will no longer be
needed. A little bit of extra work, but it has only taken me less than 2.5
hours this morning to backport the alpha patches from the most recent
snapshot to 6.5.1 tarball, so not a big deal.
Anyway, patches will be appearing shortly.
----------------------------------------------------------------------------
| "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/ |
----------------------------------------------------------------------------
On Fri, 30 Jul 1999, Ryan Kirkpatrick wrote:
> Sounds good... Only the alpha fixes don't fall under the heading
> of "*easily* fixed in -stable", so they ought to stay out of there for
> now.
If there are even pieces of the alpha patches that can be applied to the
central repository, please submit them for inclusion...#ifdef __alpha__
works quite well :) Reducing the size of the patch for each release is
always a good thing...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Fri, 30 Jul 1999, The Hermit Hacker wrote:
> On Fri, 30 Jul 1999, Ryan Kirkpatrick wrote:
>
> > Sounds good... Only the alpha fixes don't fall under the heading
> > of "*easily* fixed in -stable", so they ought to stay out of there for
> > now.
>
> If there are even pieces of the alpha patches that can be applied to the
> central repository, please submit them for inclusion...#ifdef __alpha__
> works quite well :) Reducing the size of the patch for each release is
> always a good thing...
That is what I plan to do in the coming months as I review the
alpha patches chagne by change. And yes, #ifdefs are always good to use!
:)
----------------------------------------------------------------------------
| "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/ |
----------------------------------------------------------------------------
Ryan Kirkpatrick wrote:
...
> Actually, I am working with the 6.5.1 tarball, for the simple
>reason that I want a set of patches I can post on the debian-alpha mailing
>list, along with the instructions to grab the 6.5.1 tarball from
>ftp.postgresql.org, apply patches, configure, compile, install, and they
>are set to go (No need to do a CVS pull, etc).
Hi Ryan,
I'm at a disadvantage here, because I don't have an Alpha and rely on
others on debian-alpha to get postgresql packages compiled for Alpha.
Thanks for your efforts on this.
I just want to comment on what you are saying about generating a Debian
source package. There will be a problem, because you are proposing to
provide source that will be different from the main 6.5.1 source; however,
the Debian archive assumes that source is identical across all architectures.
This means that the Alpha source for PostgreSQL must not be uploaded to the
Debian archive because it will replace the source for all other
architectures.
If this were to be a permanent problem, it could be addressed by renaming
the packages; however, this would cause a lot of trouble to many users,
so I don't want to do that when 6.6 will remove the need for it.
What I propose to do is to disable the Alpha build in the next version of
the Debian package (6.5.1-4) and make it put out information that the
Alpha source must be downloaded from <somewhere>. I would prefer that to be
in my account at www.debian.org, so that I can incorporate any changes
that go into the mainstream package.
As to producing the Alpha packages, the procedure should go something
like this:
1. Patch postgresql-6.5.1.orig (i.e. postgresql as provided at ftp.postgresql.org).
2. Examine the patches in the latest debian postgresql-6.5.1-x.diff.gz
(where x is the latest Debian release) and merge everything that does
not conflict with the new Alpha patches.
3. Update the version number in debian/changelog to 6.5.1-x.0.1alph and
build the binary packages.
4. Upload the binary packages only.
5. Put the source package in my account (and make sure I have permission
to write it!).
--
Vote against SPAM: http://www.politik-digital.de/spam/
========================================
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"And Samuel said, Hath the LORD as great delight in
burnt offerings and sacrifices, as in obeying the
voice of the LORD? Behold, to obey is better than
sacrifice, and to hearken than the fat of rams."
I Samuel 15:22
On Fri, 30 Jul 1999, Oliver Elphick wrote: > If this were to be a permanent problem, it could be addressed by renaming > the packages; however, this would cause a lot of trouble to many users, > so I don't want to do that when 6.6 will remove the need for it. > > What I propose to do is to disable the Alpha build in the next version of > the Debian package (6.5.1-4) and make it put out information that the > Alpha source must be downloaded from <somewhere>. I would prefer that to be > in my account at www.debian.org, so that I can incorporate any changes > that go into the mainstream package. What kind of patches are we dealing with? One of us could probably easily review them here and find a way to have the source patched in the event of an Alpha build environment (I already am working on a similar solution for binutils). Being pretty familiar with the postgresql source and the Alpha problems with it, feel free to mail me any patches that you want me to test (right now, I run postgresql, but have no data being served by it, so nothing's in danger). C
On Fri, 30 Jul 1999, Oliver Elphick wrote:
> Ryan Kirkpatrick wrote:
> ...
> > Actually, I am working with the 6.5.1 tarball, for the simple
> >reason that I want a set of patches I can post on the debian-alpha mailing
> >list, along with the instructions to grab the 6.5.1 tarball from
> >ftp.postgresql.org, apply patches, configure, compile, install, and they
> >are set to go (No need to do a CVS pull, etc).
>
> Hi Ryan,
> I'm at a disadvantage here, because I don't have an Alpha and rely on
> others on debian-alpha to get postgresql packages compiled for Alpha.
> Thanks for your efforts on this.
You are welcome. :)
> I just want to comment on what you are saying about generating a Debian
> source package. There will be a problem, because you are proposing to
> provide source that will be different from the main 6.5.1 source; however,
> the Debian archive assumes that source is identical across all architectures.
> This means that the Alpha source for PostgreSQL must not be uploaded to the
> Debian archive because it will replace the source for all other
> architectures.
I am well aware of this, and if I could have avoided it, I would
have. But I decided that the ablity of getting pgsql working on
linux/alpha today out weighted any transient difficulties in packaging
(that would vanish with 6.6 in a couple of months). If you think it was a
bad decision, the fault then is mine. I have been trying for 2-3 years to
get pgsql running right on linux/alpha, and don't want to hold up the best
solution we have had (ever) for another few months. That at least is the
reasons behind my actions.
> As to producing the Alpha packages, the procedure should go something
> like this:
>
> 1. Patch postgresql-6.5.1.orig (i.e. postgresql as provided at ftp.postgresql.org).
>
> 2. Examine the patches in the latest debian postgresql-6.5.1-x.diff.gz
> (where x is the latest Debian release) and merge everything that does
> not conflict with the new Alpha patches.
>
> 3. Update the version number in debian/changelog to 6.5.1-x.0.1alph and
> build the binary packages.
>
> 4. Upload the binary packages only.
>
> 5. Put the source package in my account (and make sure I have permission
> to write it!).
Ok, this I can do. It will take me about a week to get it all
done, but it does appear to be do-able. Most of the debian patches for
pgsql should apply from what I have heard (from debian-alpha people),
except for the palloc one, if memory serves me right. Either way, I should
be able to work through them given some time.
The only tricky parts are the actual uploads of the binaries and
source code... I am not a Debian developer (maybe someday, when I have
more time), and unless there is an anonymous access to the locations you
list above, I will not be able to upload them. Either provide more details
on the uploading, or I will just put both on my web site, and you can grab
them from there and put them where needed.
TTYL.
----------------------------------------------------------------------------
| "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/ |
----------------------------------------------------------------------------
On Fri, 30 Jul 1999, Christopher C Chimelis wrote:
> What kind of patches are we dealing with? One of us could probably easily
> review them here and find a way to have the source patched in the event of
> an Alpha build environment (I already am working on a similar solution for
> binutils). Being pretty familiar with the postgresql source and the Alpha
> problems with it, feel free to mail me any patches that you want me to
> test (right now, I run postgresql, but have no data being served by it, so
> nothing's in danger).
The patches are only about 60k, and apply cleanly to the 6.5.1
tarball. Once applied, pgsql will compile as per usual (as stated in the
INSTALL file). So, if you can put some conditional in the pgsql package
build to apply my patch (singular) when doing a compile on alpha, that
would be great.
If this is what you want to do, let me know, and I will not try
and generate a pgsql alpha deb myself (as Oliver asked in his email). This
will save me time and allow me to move on to actually processing the alpha
patches for the 6.6 pgsql tree.
TTYL.
----------------------------------------------------------------------------
| "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 just want to comment on what you are saying about generating a Debian
> > source package. There will be a problem, because you are proposing to
> > provide source that will be different from the main 6.5.1 source; however,
> > the Debian archive assumes that source is identical across all architectures.
The RH RPM distribution has the same constraints. I have hopes that I
can take the v6.5.1 tarball, Ryan's patches, a test on RH Alpha, and
then validate them for the i386 (and sparc, with a volunteer tester)
architectures. If that flys, then perhaps we should commit to a v6.5.2
which *does* contain these changes, but imho we should postpone the
discussion of that until we have shown exactly what it takes.
If validating on i386 succeeds, we can also do a v6.5.1+patches build
of an RPM, and presumably the Debian packaging could work this way
too. So it doesn't absolutely require a commit back to the Postgres
cvs branch if we don't have a consensus on that.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Ryan Kirkpatrick wrote:
...
> If this is what you want to do, let me know, and I will not try
>and generate a pgsql alpha deb myself (as Oliver asked in his email). This
>will save me time and allow me to move on to actually processing the alpha
>patches for the 6.6 pgsql tree.
Sorry Ryan; I had not meant that _you_ should be generating the Debian
package! I was just documenting the process.
--
Vote against SPAM: http://www.politik-digital.de/spam/
========================================
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"Have not I commanded thee? Be strong and of a good
courage; be not afraid, neither be thou dismayed; for
the LORD thy God is with thee whithersoever thou
goest." Joshua 1:9
On Sat, 31 Jul 1999, Oliver Elphick wrote:
> Ryan Kirkpatrick wrote:
> ...
> > If this is what you want to do, let me know, and I will not try
> >and generate a pgsql alpha deb myself (as Oliver asked in his email). This
> >will save me time and allow me to move on to actually processing the alpha
> >patches for the 6.6 pgsql tree.
>
> Sorry Ryan; I had not meant that _you_ should be generating the Debian
> package! I was just documenting the process.
After reading other people's responses to your email, I figured
that out. But the email was addressed to me, and only CCed to others,
so it was a bit confusing at first. :) If I can be of any help though
in gettting the alpha Pgsql deps made, (testing out debs, etc...), feel
free to ask.
----------------------------------------------------------------------------
| "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/ |
----------------------------------------------------------------------------