FAQ
============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name : Yves MARTIN
Your email address : Yves.Martin@ensimag.imag.fr

Category : runtime: back-end: SQL
Severity : non-critical

Summary: No primary key possible with type reltime & timestamp

System Configuration
--------------------
Operating System : Solaris 2.6

PostgreSQL version : 6.5

Compiler used : egcs-2.91.66

Hardware:
---------
SunOS 5.6 Generic_105181-12 sun4u sparc SUNW,Ultra-Enterprise

Versions of other tools:
------------------------


--------------------------------------------------------------------------

Problem Description:
--------------------
Error message when trying to create a table
with a primary key on type reltime or timestamp

--------------------------------------------------------------------------

Test Case:
----------
create table periodes ( b reltime primary key ) ;
ERROR: Can't find a default operator class for type 703.

create table periodes ( b timestamp primary key ) ;
ERROR: Can't find a default operator class for type 1296.


--------------------------------------------------------------------------

Solution:
---------


--------------------------------------------------------------------------

Search Discussions

  • Bruce Momjian at Jul 8, 1999 at 3:23 am
    Updated TODO item:

    * Creating index of TIMESTAMP & RELTIME fails, rename to DATETIME(Thomas)

    Problem Description:
    --------------------
    Error message when trying to create a table
    with a primary key on type reltime or timestamp

    --------------------------------------------------------------------------

    Test Case:
    ----------
    create table periodes ( b reltime primary key ) ;
    ERROR: Can't find a default operator class for type 703.

    create table periodes ( b timestamp primary key ) ;
    ERROR: Can't find a default operator class for type 1296.

    --
    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
  • Thomas Lockhart at Jul 14, 1999 at 5:46 am

    Problem Description:
    --------------------
    Error message when trying to create a table
    with a primary key on type reltime or timestamp
    Solution:
    ---------
    Use timespan and datetime instead. They are better supported; perhaps
    in the next release "reltime" and "timestamp" will simply be aliases
    for them...

    - Thomas

    --
    Thomas Lockhart lockhart@alumni.caltech.edu
    South Pasadena, California
  • Uncle George at Jul 14, 1999 at 10:24 am
    Porting:
    1) Seems like -O0/-O1 works best for this machine. It appears u get
    spin lock errors/timeouts if i optimize at -O3, and -O2

    2) in nabstime.h, the typedefs AbsoluteTime & RelativeTime ( was that
    Absolutetime & Relativetime ) should be kept at a fixed ( for all ports
    ) size like int32. Adjusting it to what ever size time_t becomes leads
    to problems with 'signed' words v. 'non-signed' extended longwords. For
    instance the constant 0x80000001 is a negative 32bit integer, but as a
    time_t it just a large positive number!.

    3) Having problems with sign extension also creates problems for '@ 3
    seconds ago'::reltime. see #2

    4) You dont store reltime or abstime as 64bit's into the db. Are there
    any plans to use 64bit alpha/linux timevalues as reltime & abstime ?
    maybe reltime64 & abstime64? whats the sql world doing with 'seconds
    since 1970' if the year is > 2038 ( which is the 32bit signed overflow )
    ?

    5) having $(CC) -mieee all over just isn't good, particular if no float
    operations are done. It slows down everthing. Is there a way to limit
    this in the makefile?
    gat

    BTW these are porting issues ( but as well hacking issues ).
  • Bruce Momjian at Jul 14, 1999 at 3:30 pm

    Porting:
    1) Seems like -O0/-O1 works best for this machine. It appears u get
    spin lock errors/timeouts if i optimize at -O3, and -O2
    Yes, the 6.5.1 code will use:

    CFLAGS:-O -mieee # optimization -O2 removed because of egcs problem
    2) in nabstime.h, the typedefs AbsoluteTime & RelativeTime ( was that
    Absolutetime & Relativetime ) should be kept at a fixed ( for all ports
    ) size like int32. Adjusting it to what ever size time_t becomes leads
    to problems with 'signed' words v. 'non-signed' extended longwords. For
    instance the constant 0x80000001 is a negative 32bit integer, but as a
    time_t it just a large positive number!.
    OK, the real problem is that we are using "magic" values to mark certain
    values, and this is not done portably. Can you suggestion good values?
    Can you send over a patch?
    3) Having problems with sign extension also creates problems for '@ 3
    seconds ago'::reltime. see #2
    Same thing. We should not be using hard-coded values.
    4) You dont store reltime or abstime as 64bit's into the db. Are there
    any plans to use 64bit alpha/linux timevalues as reltime & abstime ?
    maybe reltime64 & abstime64? whats the sql world doing with 'seconds
    since 1970' if the year is > 2038 ( which is the 32bit signed overflow )
    ?
    Not sure on this.
    5) having $(CC) -mieee all over just isn't good, particular if no float
    operations are done. It slows down everthing. Is there a way to limit
    this in the makefile?
    gat
    What does that flag do, and where would it be needed or not needed?

    --
    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
  • Uncle George at Jul 15, 1999 at 12:43 am
    Well, a reply, anyway

    1) reltime & abstime values are stored in the DB as 4 byte values. The
    definitions for abstime&reltime are also stored in the DB ( this from empiracle
    debugging ) . If you do not plan to embrace the notion of #of seconds >
    2^(32-1), and you dont want to alter the DB notion that storage is 4 bytes then

    typedef int32 Absolutetime;
    typedef int32 Relativetime;

    would appear to be most preferable & more stable (majic #'s work ) than

    typedef time_t Absolutetime;
    typedef time_t Relativetime;

    This is not a complete solution , as there are still some sign extension
    problems as demonstratable by the regression tests.
    If you want to use 64bit Absolutetime & reltimes, then you should adjust (
    or make more abstract ) the concept of abstime&reltime. BUT
    THIS IS NOT A PORTING ISSUE! I would just like to get the abstime*reltime to
    behave much like the 32bit folks.

    2) Can u add HAS_LONG_LONG to $(CFLAGS)
    I dont have long long, but it turns on some code ( somewhere ) that fixes
    another problem.

    3) -mieee informs the egcs compiler fot the alpha to inject 'trapb'
    instructions at various places in a floating point computation. The trapb is a
    pipeline stall forcing the processor to stop issueing instructions until all
    current instructions in the pipeline have executed. This is done to capture a
    possible 'fault' at a resomable time so you can backtrack to the instruction
    that faulted and take some corrective measure. There are also rules for
    backtracing, and repairing. The usage of -mieee inserted these trapb's all over
    the place. The current egcs compiler appears to do a better job at it For
    purely int operations, then a module need not be enhanced by the -mieee switch.

    4) I'd give u some patches, but still getting the regression tests to work.
    Where do I get 6.5.1, so I can work with that as a base

    5) What is the floating point rounding set to ( up/down ). There seems to be an
    extra digit of precision in ur i386, where the alpha port appears to round up (
    and have 1 digit less :( )

    gat

    Bruce Momjian wrote:
    Porting:
    1) Seems like -O0/-O1 works best for this machine. It appears u get
    spin lock errors/timeouts if i optimize at -O3, and -O2
    Yes, the 6.5.1 code will use:

    CFLAGS:-O -mieee # optimization -O2 removed because of egcs problem
    2) in nabstime.h, the typedefs AbsoluteTime & RelativeTime ( was that
    Absolutetime & Relativetime ) should be kept at a fixed ( for all ports
    ) size like int32. Adjusting it to what ever size time_t becomes leads
    to problems with 'signed' words v. 'non-signed' extended longwords. For
    instance the constant 0x80000001 is a negative 32bit integer, but as a
    time_t it just a large positive number!.
    OK, the real problem is that we are using "magic" values to mark certain
    values, and this is not done portably. Can you suggestion good values?
    Can you send over a patch?
    3) Having problems with sign extension also creates problems for '@ 3
    seconds ago'::reltime. see #2
    Same thing. We should not be using hard-coded values.
    4) You dont store reltime or abstime as 64bit's into the db. Are there
    any plans to use 64bit alpha/linux timevalues as reltime & abstime ?
    maybe reltime64 & abstime64? whats the sql world doing with 'seconds
    since 1970' if the year is > 2038 ( which is the 32bit signed overflow )
    ?
    Not sure on this.
    5) having $(CC) -mieee all over just isn't good, particular if no float
    operations are done. It slows down everthing. Is there a way to limit
    this in the makefile?
    gat
    What does that flag do, and where would it be needed or not needed?

    --
    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
  • Bruce Momjian at Jul 15, 1999 at 3:13 am

    Well, a reply, anyway

    1) reltime & abstime values are stored in the DB as 4 byte values. The
    definitions for abstime&reltime are also stored in the DB ( this from empiracle
    debugging ) . If you do not plan to embrace the notion of #of seconds >
    2^(32-1), and you dont want to alter the DB notion that storage is 4 bytes then

    typedef int32 Absolutetime;
    typedef int32 Relativetime;

    would appear to be most preferable & more stable (majic #'s work ) than

    typedef time_t Absolutetime;
    typedef time_t Relativetime;

    This is not a complete solution , as there are still some sign extension
    problems as demonstratable by the regression tests.
    If you want to use 64bit Absolutetime & reltimes, then you should adjust (
    or make more abstract ) the concept of abstime&reltime. BUT
    THIS IS NOT A PORTING ISSUE! I would just like to get the abstime*reltime to
    behave much like the 32bit folks.
    Makes sense. Using time_t does not make sense if we are forcing
    everything to 4 bytes.
    2) Can u add HAS_LONG_LONG to $(CFLAGS)
    I dont have long long, but it turns on some code ( somewhere ) that fixes
    another problem.
    Check configure. It runs a test to see if long long works, and sets that
    in include/config.h.
    3) -mieee informs the egcs compiler fot the alpha to inject 'trapb'
    instructions at various places in a floating point computation. The trapb is a
    pipeline stall forcing the processor to stop issueing instructions until all
    current instructions in the pipeline have executed. This is done to capture a
    possible 'fault' at a resomable time so you can backtrack to the instruction
    that faulted and take some corrective measure. There are also rules for
    backtracing, and repairing. The usage of -mieee inserted these trapb's all over
    the place. The current egcs compiler appears to do a better job at it For
    purely int operations, then a module need not be enhanced by the -mieee switch.
    I am stumped on why we even need -mieee, but someone supplied a patch to
    add it.
    4) I'd give u some patches, but still getting the regression tests to work.
    Where do I get 6.5.1, so I can work with that as a base
    Go to ftp.postgresql.org, and get the "snapshot". That will be 6.5.1 on
    July 19th.
    5) What is the floating point rounding set to ( up/down ). There seems to be an
    extra digit of precision in ur i386, where the alpha port appears to round up (
    and have 1 digit less :( )
    Not sure where that is set. Would be fpsetround() on BSD/OS, however, I
    don't see us setting it anywhere, so my guess is that we are using the
    OS default for 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
  • Uncle George at Jul 15, 1999 at 10:45 am
    1) The reason why for -mieee is that if u care for some of the 'rare' floating point
    exceptions ( as defined by alpha floating point hardware ) then u want to handle
    them - as per ieee specifications to give u the correct ieee result. When the
    processor cant handle the exceptions it (can ) traps to software assist routines
    ( hidden in the kernel ). But in order for the kernel to fix the exception u have to
    stop the pipeline as close to the problem, so u can backtrace the user pc ( which is
    by now quite a few instructions ahead of where the exception occured ) to the point
    where it occured to see what register needs to have the correct value inserted.
    Without the -mieee, the compiler will not arrange the float operations so that
    it can be backstepped when a fault occures. The kernel then cannot fix the problem,
    and forces a floating point exception onto the program. Death usually follows.
    Therefor only do -mieee where u need to. ERGO can this flag be set individually
    as per each individual makefile, and not as per ./configure ?
    2) Then I want to report a bug - HAS_LONG_LONG in one of the 'c' files needs to be
    turned on - I think there is only one - also for RH6.0/alpha. I dont think that
    RH6.0/alpha has long long as a type and just uses long to define a 64bit quantity
    3) Then can I presume that Absolutetime/Relativetime in nabstime.h will be changed
    to int32?

    Bruce Momjian wrote:
    Well, a reply, anyway

    1) reltime & abstime values are stored in the DB as 4 byte values. The
    definitions for abstime&reltime are also stored in the DB ( this from empiracle
    debugging ) . If you do not plan to embrace the notion of #of seconds >
    2^(32-1), and you dont want to alter the DB notion that storage is 4 bytes then

    typedef int32 Absolutetime;
    typedef int32 Relativetime;

    would appear to be most preferable & more stable (majic #'s work ) than

    typedef time_t Absolutetime;
    typedef time_t Relativetime;

    This is not a complete solution , as there are still some sign extension
    problems as demonstratable by the regression tests.
    If you want to use 64bit Absolutetime & reltimes, then you should adjust (
    or make more abstract ) the concept of abstime&reltime. BUT
    THIS IS NOT A PORTING ISSUE! I would just like to get the abstime*reltime to
    behave much like the 32bit folks.
    Makes sense. Using time_t does not make sense if we are forcing
    everything to 4 bytes.
    2) Can u add HAS_LONG_LONG to $(CFLAGS)
    I dont have long long, but it turns on some code ( somewhere ) that fixes
    another problem.
    Check configure. It runs a test to see if long long works, and sets that
    in include/config.h.
    3) -mieee informs the egcs compiler fot the alpha to inject 'trapb'
    instructions at various places in a floating point computation. The trapb is a
    pipeline stall forcing the processor to stop issueing instructions until all
    current instructions in the pipeline have executed. This is done to capture a
    possible 'fault' at a resomable time so you can backtrack to the instruction
    that faulted and take some corrective measure. There are also rules for
    backtracing, and repairing. The usage of -mieee inserted these trapb's all over
    the place. The current egcs compiler appears to do a better job at it For
    purely int operations, then a module need not be enhanced by the -mieee switch.
    I am stumped on why we even need -mieee, but someone supplied a patch to
    add it.
    4) I'd give u some patches, but still getting the regression tests to work.
    Where do I get 6.5.1, so I can work with that as a base
    Go to ftp.postgresql.org, and get the "snapshot". That will be 6.5.1 on
    July 19th.
    5) What is the floating point rounding set to ( up/down ). There seems to be an
    extra digit of precision in ur i386, where the alpha port appears to round up (
    and have 1 digit less :( )
    Not sure where that is set. Would be fpsetround() on BSD/OS, however, I
    don't see us setting it anywhere, so my guess is that we are using the
    OS default for this.
  • Bruce Momjian at Jul 15, 1999 at 1:42 pm

    1) The reason why for -mieee is that if u care for some of the 'rare' floating point
    exceptions ( as defined by alpha floating point hardware ) then u want to handle
    them - as per ieee specifications to give u the correct ieee result. When the
    processor cant handle the exceptions it (can ) traps to software assist routines
    ( hidden in the kernel ). But in order for the kernel to fix the exception u have to
    stop the pipeline as close to the problem, so u can backtrace the user pc ( which is
    by now quite a few instructions ahead of where the exception occured ) to the point
    where it occured to see what register needs to have the correct value inserted.
    Without the -mieee, the compiler will not arrange the float operations so that
    it can be backstepped when a fault occures. The kernel then cannot fix the problem,
    and forces a floating point exception onto the program. Death usually follows.
    Therefor only do -mieee where u need to. ERGO can this flag be set individually
    as per each individual makefile, and not as per ./configure ?
    Right now, it is hard to have makefile-specific flags.
    2) Then I want to report a bug - HAS_LONG_LONG in one of the 'c' files needs to be
    turned on - I think there is only one - also for RH6.0/alpha. I dont think that
    RH6.0/alpha has long long as a type and just uses long to define a 64bit quantity
    Add 'set -x' to configure, and figure how how the test is working in
    configure. Look at the configure output. It shows how it is setting
    those flags.
    3) Then can I presume that Absolutetime/Relativetime in nabstime.h will be changed
    to int32?
    Added to TODO:

    * Make Absolutetime/Relativetime int4 because time_t can be int8 on some ports


    --
    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
  • Uncle George at Jul 20, 1999 at 12:29 am
    In the regression test rules.sql there is this SQL command

    update rtest_v1 set a = rtest_t3.a + 20 where b = rtest_t3.b;

    Which causes my alpha port to go core. The above line can be reduced to:

    update rtest_v1 set a = rtest_t3.a + 20 ;

    which also causes the same problem. It seems that the 64 bit address
    ((Expr*)nodeptr)->oper gets truncated ( high 32 bits ) somewhere along the way.

    I was able to locate the errant code in rewriteManip.c:712. but There seems to be a
    bigger problem other than eraseing the upper 32bit address. It seems that
    FindMatchingNew() returns a node of type T_Expr, rather than the expected type of
    T_Var. Once u realize this then u can see why the now MISCAST "(Var *)
    *nodePtr)->varlevelsup = this_varlevelsup" will cause a problem. On my alpha this erases
    a portion in the address in the T_Expr. On the redhat 5.2/i386 this code seems to be
    benign, BUT YOU ARE ERASEING SOMETHING that doesn't belong to to T_Expr !

    So what gives?
    gat
    Maybe an assert() will help in finding some of the miscast returned types? Wuddya think?
    sure would catch some of the boo-boo's hanging around

    rewriteManip.c:
    if (this_varno == info->new_varno &&
    this_varlevelsup == sublevels_up)
    {
    n = FindMatchingNew(targetlist,
    ((Var *) node)->varattno);
    if (n == NULL)
    {
    if (info->event == CMD_UPDATE)
    {
    *nodePtr = n = copyObject(node);
    ((Var *) n)->varno = info->current_varno;
    ((Var *) n)->varnoold = info->current_varno;
    }
    else
    *nodePtr = make_null(((Var *) node)->vartype);
    }
    else
    {
    *nodePtr = copyObject(n);
    ((Var *) *nodePtr)->varlevelsup = this_varlevelsup; /* This
    line zaps the address */
    }
    }
  • Tom Lane at Jul 20, 1999 at 2:15 am

    Uncle George writes:
    In the regression test rules.sql there is this SQL command
    update rtest_v1 set a = rtest_t3.a + 20 where b = rtest_t3.b;
    Which causes my alpha port to go core.
    Yeah. This was reported by Pedro Lobo on 11 June, and we've been
    patiently waiting for Jan to decide what to do about it :-(

    You could stop the coredump by putting a test into ResolveNew:

    {
    *nodePtr = copyObject(n);
    + if (IsA(*nodePtr, Var))
    ((Var *) *nodePtr)->varlevelsup = this_varlevelsup;
    }

    but what's not so clear is what's supposed to happen when the
    replacement item *isn't* a Var. I tried to convince myself that nothing
    needed to happen in that case, but wasn't successful. (Presumably the
    replacement expression contains no instances of the variable being
    replaced, so recursing into it with ResolveNew shouldn't be needed
    --- but maybe its varlevelsup values need adjusted?)

    regards, tom lane
  • Ryan Kirkpatrick at Jul 20, 1999 at 1:05 am

    On Wed, 14 Jul 1999, Bruce Momjian wrote:

    3) -mieee informs the egcs compiler fot the alpha to inject 'trapb'
    instructions at various places in a floating point computation. The trapb is a
    pipeline stall forcing the processor to stop issueing instructions until all
    current instructions in the pipeline have executed. This is done to capture a
    possible 'fault' at a resomable time so you can backtrack to the instruction
    that faulted and take some corrective measure. There are also rules for
    backtracing, and repairing. The usage of -mieee inserted these trapb's all over
    the place. The current egcs compiler appears to do a better job at it For
    purely int operations, then a module need not be enhanced by the -mieee switch.
    I am stumped on why we even need -mieee, but someone supplied a patch to
    add it.
    That someone would be me. :) I supplied a patch to add about a
    year ago as that was the only way I could get some of the date/time code
    work correctly. If it is needed anywhere anymore, then it is down in
    src/backend/util/adt, as that is where the datetime code is/was that were
    causing FPEs to occur on regression testing. Without that flag, the
    datetime code used to blow up all over the place. Might be worthwhile to
    try removing it, recompiling, and running regression tests to see if it
    needed anymore. That, and fixing the datetime code so it is not needed in
    the first place (if it is still needed).
    The biggest problem area for pgsql on Linux/Alpha at the moment is
    in the datetime code, including what reltime and abstime regression tests
    exercise.
    If anyone wants me to test pgsql patches on Alpha, feel free to
    send them my way, and I will give them a test on my XL366 Alpha running
    Debian 2.1.
    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/ |
    ----------------------------------------------------------------------------
  • Uncle George at Jul 20, 1999 at 1:27 am
    Thats NOT THE PROBLEM.
    Although u have localize the -mieee/float in the date stuff, u have needlessly
    inflicted the -mieee switch on ALL compiled modules.
    I would have prefered it to be makefile ( Certainly on a SUBSYS.o, and even better on
    on a per module.o) compile under a makefile switch
    ie: ( or something simular )

    if eq($(CPUID),alpha)
    myfloat.o: myfloat.c
    $(CC) $(CFLAGS) -mieee myfloat.c -o myfloat.o
    fi


    Ryan Kirkpatrick wrote:
    On Wed, 14 Jul 1999, Bruce Momjian wrote:

    3) -mieee informs the egcs compiler fot the alpha to inject 'trapb'
    I am stumped on why we even need -mieee, but someone supplied a patch to
    add it.
    That someone would be me. :) I supplied a patch to add about a
    year ago as that was the only way I could get some of the date/time code
    w
  • Bruce Momjian at Jul 20, 1999 at 2:47 am

    Thats NOT THE PROBLEM.
    Although u have localize the -mieee/float in the date stuff, u have needlessly
    inflicted the -mieee switch on ALL compiled modules.
    I would have prefered it to be makefile ( Certainly on a SUBSYS.o, and even better on
    on a per module.o) compile under a makefile switch
    ie: ( or something simular )

    if eq($(CPUID),alpha)
    myfloat.o: myfloat.c
    $(CC) $(CFLAGS) -mieee myfloat.c -o myfloat.o
    fi
    OK, I have added code in utils/adt/Makefile as:

    # seems to be required for some date/time stuff 07/19/1999 bjm
    ifeq ($(CPU),alpha)
    CFLAGS+= -mieee
    endif

    This is in the current tree, not 6.5.1. Please test and let me know if
    this helps. I also added a Makefile-visible variable called CPU. Seems
    we really don't have such a variable already available in the
    Makefile-scope.



    --
    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
  • Thomas Lockhart at Jul 20, 1999 at 5:10 am

    if eq($(CPUID),alpha)
    myfloat.o: myfloat.c
    $(CC) $(CFLAGS) -mieee myfloat.c -o myfloat.o
    fi
    # seems to be required for some date/time stuff 07/19/1999 bjm
    ifeq ($(CPU),alpha)
    CFLAGS+= -mieee
    endif
    This is in the current tree, not 6.5.1. Please test and let me know
    if this helps. I also added a Makefile-visible variable called CPU.
    Seems we really don't have such a variable already available in the
    Makefile-scope.
    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...

    - Thomas

    --
    Thomas Lockhart lockhart@alumni.caltech.edu
    South Pasadena, California
  • Uncle George at Jul 20, 1999 at 3:00 pm

    Thomas Lockhart wrote:

    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).
    Well, in order to do this properly for linux/alpha & the egcs compiler u
    need to know more, or realize more on the dangers of casting. Please
    note that I haven't said improperly, blithely, or arbitarily. Things
    just happen in the alpha if things are not properly casted. In the case
    of postgres this happens to be a (major) problem with function calls &
    function parameters. I have fixed just enough to get the regression
    tests to work.
    BTW I'd really love to have a redhat 6.0/alpha cd but not at the going
    price of $79.00

    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...
    What is PORTNAME. i ( as well as others ) use uname.
  • Thomas Lockhart at Jul 20, 1999 at 3:21 pm

    RedHat is interested in doing a maintenance release of Postgres
    rpms
    I have fixed just enough to get the regression
    tests to work.
    BTW I'd really love to have a redhat 6.0/alpha cd but not at the going
    price of $79.00
    I heard that Costco (a discounting volume retailer) has the grey-box
    (MacMillan?) version of RH6.0 for $25...
    What is PORTNAME. i ( as well as others ) use uname.
    It is defined in src/Makefile.global. We would need to be able to
    check for both OS (linux) and architecture (alpha); perhaps Bruce's
    recent change to give a "CPU" variable is just what we need. I'll add
    the PORTNAME check to the relevant Makefile.

    If you can send patches for what you have changed, I can incorporate
    them into an RPM for testing (built on a RH5.2-i686 box, but the
    source rpm can be rebuilt on yours).

    - Thomas

    --
    Thomas Lockhart lockhart@alumni.caltech.edu
    South Pasadena, California
  • Bruce Momjian at Jul 20, 1999 at 4:49 pm

    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.

    --
    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
  • Thomas Lockhart at Jul 21, 1999 at 5:38 am

    OK, I have made it:

    ifeq ($(CPU),alpha)
    ifeq ($(CC), gcc)
    CFLAGS+= -mieee
    endif
    ifeq ($(CC), egcs)
    CFLAGS+= -mieee
    endif
    endif
    Great. I think that is closer to what is needed...

    - Thomas

    --
    Thomas Lockhart lockhart@alumni.caltech.edu
    South Pasadena, California
  • Ryan Kirkpatrick at Jul 22, 1999 at 1:39 am

    On Mon, 19 Jul 1999, Uncle George wrote:

    Although u have localize the -mieee/float in the date stuff, u have needlessly
    inflicted the -mieee switch on ALL compiled modules.
    I did that originally to see if it would solve any other of the
    problems that the regression tests were revealing at that time. Though, I
    will admit it was a mistake to leave it as a global flag without more
    research into if it helped anywhere or not. Unfortuntely, I got busy with
    school about then and never got back to it. :(

    ----------------------------------------------------------------------------
    "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/ |
    ----------------------------------------------------------------------------
  • Bruce Momjian at Jul 20, 1999 at 6:02 pm

    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
  • Uncle George at Jul 22, 1999 at 5:57 pm
    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
  • Bruce Momjian at Jul 22, 1999 at 6:31 pm
    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
  • Uncle George at Jul 23, 1999 at 1:58 am
    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.
  • Bruce Momjian at Jul 23, 1999 at 2:02 am

    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
  • Bruce Momjian at Jul 22, 1999 at 6:31 pm

    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
  • Ryan Kirkpatrick at Jul 23, 1999 at 2:24 am

    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/ |
    ----------------------------------------------------------------------------
  • Bruce Momjian at Jul 23, 1999 at 2:39 am

    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
  • Ryan Kirkpatrick at Jul 23, 1999 at 3:05 am

    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/ |
    ----------------------------------------------------------------------------
  • Thomas Lockhart at Jul 27, 1999 at 2:42 pm

    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
  • Bruce Momjian at Jul 27, 1999 at 3:30 pm

    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
  • Thomas Lockhart at Jul 27, 1999 at 3:43 pm

    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
  • Ryan Kirkpatrick at Jul 27, 1999 at 7:49 pm

    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/ |
    ----------------------------------------------------------------------------
  • Thomas Lockhart at Jul 28, 1999 at 2:35 pm

    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
  • Ryan Kirkpatrick at Jul 29, 1999 at 3:18 am

    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/ |
    ----------------------------------------------------------------------------
  • Bruce Momjian at Jul 29, 1999 at 3:28 am

    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
  • Ryan Kirkpatrick at Jul 29, 1999 at 2:33 pm
    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/ |
    ----------------------------------------------------------------------------
  • Bruce Momjian at Jul 29, 1999 at 2:44 pm

    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
  • Ryan Kirkpatrick at Jul 29, 1999 at 3:14 pm

    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/ |
    ----------------------------------------------------------------------------
  • Thomas Lockhart at Jul 29, 1999 at 3:32 pm

    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
  • Bruce Momjian at Jul 29, 1999 at 3:47 pm

    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
  • Thomas Lockhart at Jul 29, 1999 at 4:05 pm

    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
  • Bruce Momjian at Jul 29, 1999 at 4:31 pm

    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
  • Ryan Kirkpatrick at Jul 29, 1999 at 5:05 pm

    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/ |
    ----------------------------------------------------------------------------
  • Bruce Momjian at Jul 29, 1999 at 5:31 pm

    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
  • Thomas Lockhart at Jul 30, 1999 at 12:16 am

    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
  • Bruce Momjian at Jul 30, 1999 at 12:44 am

    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
  • The Hermit Hacker at Jul 30, 1999 at 1:28 am
    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
  • Ryan Kirkpatrick at Jul 30, 1999 at 3:30 am

    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/ |
    ----------------------------------------------------------------------------
  • Lamar Owen at Jul 30, 1999 at 1:29 am

    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
  • Ryan Kirkpatrick at Jul 30, 1999 at 3:04 am

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-ports @
categoriespostgresql
postedJul 7, '99 at 8:20a
activeJul 31, '99 at 5:02p
posts93
users11
websitepostgresql.org
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase