Thread

Re: [PORTS] RedHat6.0 & Alpha

Bruce Momjian <maillist@candle.pha.pa.us> — 1999-07-20T17:36:30Z

> > 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

Re: [PORTS] RedHat6.0 & Alpha

Uncle George <gatgul@voicenet.com> — 1999-07-22T17:50:57Z

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

Re: [PORTS] RedHat6.0 & Alpha

Uncle George <gatgul@voicenet.com> — 1999-07-22T18:20:13Z

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)

~
~

Re: [PORTS] RedHat6.0 & Alpha

Bruce Momjian <maillist@candle.pha.pa.us> — 1999-07-22T18:29:14Z

> 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

Re: [PORTS] RedHat6.0 & Alpha

Bruce Momjian <maillist@candle.pha.pa.us> — 1999-07-22T18:30:31Z

> 
>     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

Re: [PORTS] RedHat6.0 & Alpha

Uncle George <gatgul@voicenet.com> — 1999-07-23T01:52:19Z

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

Re: [PORTS] RedHat6.0 & Alpha

Bruce Momjian <maillist@candle.pha.pa.us> — 1999-07-23T02:01:49Z

> 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

Re: [PORTS] RedHat6.0 & Alpha

Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu> — 1999-07-23T02:23:34Z

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/                |
----------------------------------------------------------------------------

Re: [PORTS] RedHat6.0 & Alpha

Bruce Momjian <maillist@candle.pha.pa.us> — 1999-07-23T02:39:25Z

> 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

Re: [PORTS] RedHat6.0 & Alpha

Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu> — 1999-07-23T03:05:11Z

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/                |
----------------------------------------------------------------------------

Re: [PORTS] RedHat6.0 & Alpha

Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-07-23T04:33:28Z

> 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

Re: [PORTS] RedHat6.0 & Alpha

Uncle George <gatgul@voicenet.com> — 1999-07-23T11:26:03Z

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)...

Re: [PORTS] RedHat6.0 & Alpha

Peter Galbavy <peter.galbavy@knowledge.com> — 1999-07-23T13:46:44Z

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/

Re: [PORTS] RedHat6.0 & Alpha

Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-07-23T13:47:11Z

>     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

Re: [PORTS] RedHat6.0 & Alpha

Bruce Momjian <maillist@candle.pha.pa.us> — 1999-07-23T16:30:27Z

> 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

Re: [PORTS] RedHat6.0 & Alpha

Uncle George <gatgul@voicenet.com> — 1999-07-23T17:35:41Z

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

Re: [PORTS] RedHat6.0 & Alpha & postgresql

Uncle George <gatgul@voicenet.com> — 1999-07-26T20:32:25Z

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

Re: [PORTS] RedHat6.0 & Alpha & postgresql

Bruce Momjian <maillist@candle.pha.pa.us> — 1999-07-27T03:04:05Z

> 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

Re: [PORTS] RedHat6.0 & Alpha

Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-07-27T14:39:31Z

> > > 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

Re: [PORTS] RedHat6.0 & Alpha

Bruce Momjian <maillist@candle.pha.pa.us> — 1999-07-27T15:12:10Z

> > > > 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

Re: [PORTS] RedHat6.0 & Alpha

Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-07-27T15:43:35Z

> 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

Re: [PORTS] RedHat6.0 & Alpha

Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu> — 1999-07-27T19:48:49Z

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/                |
----------------------------------------------------------------------------

Re: [PORTS] RedHat6.0 & Alpha

Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-07-28T14:34:56Z

> > 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

Re: [PORTS] RedHat6.0 & Alpha

Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu> — 1999-07-29T03:18:23Z

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/                |
----------------------------------------------------------------------------

Re: [PORTS] RedHat6.0 & Alpha

Bruce Momjian <maillist@candle.pha.pa.us> — 1999-07-29T03:27:35Z

> 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

Re: [PORTS] RedHat6.0 & Alpha

Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu> — 1999-07-29T14:33:02Z

	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/                |
----------------------------------------------------------------------------

Re: [PORTS] RedHat6.0 & Alpha

Bruce Momjian <maillist@candle.pha.pa.us> — 1999-07-29T14:41:29Z

> 
> 	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

Re: [PORTS] RedHat6.0 & Alpha

Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-07-29T14:44:31Z

> 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

Re: [PORTS] RedHat6.0 & Alpha

Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu> — 1999-07-29T15:14:12Z

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/                |
----------------------------------------------------------------------------

Re: [PORTS] RedHat6.0 & Alpha

Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-07-29T15:32:01Z

> > 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

Re: [PORTS] RedHat6.0 & Alpha

Bruce Momjian <maillist@candle.pha.pa.us> — 1999-07-29T15:44:31Z

> > > 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

Re: [PORTS] RedHat6.0 & Alpha

Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-07-29T16:05:15Z

> 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

Re: [PORTS] RedHat6.0 & Alpha

Bruce Momjian <maillist@candle.pha.pa.us> — 1999-07-29T16:08:24Z

> 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

Re: [PORTS] RedHat6.0 & Alpha

Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu> — 1999-07-29T16:30:52Z

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/                |
----------------------------------------------------------------------------

Re: [PORTS] RedHat6.0 & Alpha

Bruce Momjian <maillist@candle.pha.pa.us> — 1999-07-29T17:03:43Z

> 	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

Re: [PORTS] RedHat6.0 & Alpha

Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu> — 1999-07-29T17:04:54Z

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/                |
----------------------------------------------------------------------------

Re: [PORTS] RedHat6.0 & Alpha

Bruce Momjian <maillist@candle.pha.pa.us> — 1999-07-29T17:08:38Z

> 	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

Re: [PORTS] RedHat6.0 & Alpha

Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-07-30T00:16:03Z

> > 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

Re: [PORTS] RedHat6.0 & Alpha

Bruce Momjian <maillist@candle.pha.pa.us> — 1999-07-30T00:40:53Z

> 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

Re: [PORTS] RedHat6.0 & Alpha

Lamar Owen <lamar.owen@wgcr.org> — 1999-07-30T00:44:12Z

> 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

Re: [HACKERS] Re: [PORTS] RedHat6.0 & Alpha

Marc G. Fournier <scrappy@hub.org> — 1999-07-30T01:27:05Z

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

Re: [PORTS] RedHat6.0 & Alpha

Marc G. Fournier <scrappy@hub.org> — 1999-07-30T01:30:10Z

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

Re: [PORTS] RedHat6.0 & Alpha

Bruce Momjian <maillist@candle.pha.pa.us> — 1999-07-30T01:36:40Z

> 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

Re: [PORTS] RedHat6.0 & Alpha

Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu> — 1999-07-30T02:28:42Z

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/                |
----------------------------------------------------------------------------

Re: [PORTS] RedHat6.0 & Alpha

Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu> — 1999-07-30T02:34:28Z

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/                |
----------------------------------------------------------------------------

Re: [PORTS] RedHat6.0 & Alpha

Bruce Momjian <maillist@candle.pha.pa.us> — 1999-07-30T02:44:21Z

> > 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

Re: [PORTS] RedHat6.0 & Alpha

Bruce Momjian <maillist@candle.pha.pa.us> — 1999-07-30T02:45:19Z

> > 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

Re: [PORTS] RedHat6.0 & Alpha

Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu> — 1999-07-30T03:03:41Z

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/                |
----------------------------------------------------------------------------

Re: [HACKERS] Re: [PORTS] RedHat6.0 & Alpha

Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu> — 1999-07-30T03:30:14Z

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/                |
----------------------------------------------------------------------------

Re: [HACKERS] Re: [PORTS] RedHat6.0 & Alpha

Marc G. Fournier <scrappy@hub.org> — 1999-07-30T03:36:10Z

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

Re: [PORTS] RedHat6.0 & Alpha

Bruce Momjian <maillist@candle.pha.pa.us> — 1999-07-30T03:52:59Z

> 	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

Re: [HACKERS] Re: [PORTS] RedHat6.0 & Alpha

Marc G. Fournier <scrappy@hub.org> — 1999-07-30T04:36:57Z

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

Re: [HACKERS] Re: [PORTS] RedHat6.0 & Alpha

Bruce Momjian <maillist@candle.pha.pa.us> — 1999-07-30T05:25:23Z

> 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

Re: [PORTS] RedHat6.0 & Alpha

Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-07-30T13:42:40Z

> > 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

Re: [HACKERS] Re: [PORTS] RedHat6.0 & Alpha

Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu> — 1999-07-30T14:32:25Z

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/                |
----------------------------------------------------------------------------

Re: [HACKERS] Re: [PORTS] RedHat6.0 & Alpha

Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu> — 1999-07-30T15:17:33Z

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/                |
----------------------------------------------------------------------------

Re: [PORTS] RedHat6.0 & Alpha

Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu> — 1999-07-30T15:21:55Z

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/                |
----------------------------------------------------------------------------

Re: [PORTS] RedHat6.0 & Alpha

Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu> — 1999-07-30T15:32:44Z

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/                |
----------------------------------------------------------------------------

Re: [PORTS] RedHat6.0 & Alpha

Bruce Momjian <maillist@candle.pha.pa.us> — 1999-07-30T15:51:29Z

> > 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

Re: [PORTS] RedHat6.0 & Alpha

Bruce Momjian <maillist@candle.pha.pa.us> — 1999-07-30T16:04:01Z

> > 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

Stable vs Current (Was: Re: [HACKERS] Re: [PORTS] RedHat6.0 & Alpha)

Marc G. Fournier <scrappy@hub.org> — 1999-07-30T16:08:06Z

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

Re: Stable vs Current (Was: Re: [HACKERS] Re: [PORTS] RedHat6.0 & Alpha)

Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu> — 1999-07-30T16:31:52Z

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/                |
----------------------------------------------------------------------------

Re: Stable vs Current (Was: Re: [HACKERS] Re: [PORTS] RedHat6.0 & Alpha)

Marc G. Fournier <scrappy@hub.org> — 1999-07-30T16:56:23Z

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

Re: Stable vs Current (Was: Re: [HACKERS] Re: [PORTS] RedHat6.0 & Alpha)

Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu> — 1999-07-30T17:25:29Z

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/                |
----------------------------------------------------------------------------