FAQ
Are we still scheduled for a 6.1p1 release?

We are continuing to get inter-platform endian bug reports, and missing
ENDIAN define bug reports, and we have fixed a few latent bugs.

I think it is worth while to generate an official 6.1p1. I will do the
HISTORY file.

Don't wait for my psort() changes. They are not that important, and I
am still reading Knuth to make sure I have all the areas covered.

- --
Bruce Momjian
maillist@candle.pha.pa.us

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

Search Discussions

  • Darren King at Jul 1, 1997 at 2:21 pm

    We are continuing to get inter-platform endian bug reports, and missing
    ENDIAN define bug reports, and we have fixed a few latent bugs.
    Problem wasn't really with the postgres code as much as it was the drivers.
    Appears to me that they are not using the hton/ntoh, but always expecting
    little endian.

    Don't wait for my psort() changes. They are not that important, and I
    am still reading Knuth to make sure I have all the areas covered.
    FYI - Article in this months C/C++ Users Journal about sorting with memory
    and disk/tape. Quite a bit of _C++_ code with it, but maybe some of the
    it would be useful.


    darrenk

    ------------------------------
  • Thomas G. Lockhart at Jul 1, 1997 at 4:13 pm

    Are we still scheduled for a 6.1p1 release?
    We are continuing to get inter-platform endian bug reports, and missing
    ENDIAN define bug reports, and we have fixed a few latent bugs.

    I think it is worth while to generate an official 6.1p1. I will do the
    HISTORY file.
    I agree that a patch release would be useful. I'd really like to see a
    snapshot release (or two) and a few days for beta testing by the folks
    who have reported problems before we do a release.

    Don't see any snapshot releases though; are they somewhere different
    than usual?? Something seems to have broken on June 13, leaving a 10MB
    file and other bits and pieces in /pub/6.1; /pub/6.2 doesn't seem to be
    generating anything other than empty change files.

    - Tom

    ------------------------------
  • Michael Reifenberger at Jul 1, 1997 at 4:42 pm
    Hi,
    is it just me?

    Is 31th of a month allways valid?

    - -----------------------------------------------------------
    plaut=> drop table x;
    DROP
    plaut=> create table x ( x datetime );
    CREATE
    plaut=> insert into x values ( 'Jun 31 12:01:00 1997 GMT');
    - --- ^^^^^^
    INSERT 423830
    plaut=> select * from x;
    ...
    Tue Jul 01 14:01:00.00 1997 MET DST
    (1 row)

    plaut=> insert into x values ( 'Jun 32 12:01:00 1997 GMT');
    - --- ^^^^^^
    WARN:Bad datetime external representation Jun 32 12:01:00 1997 GMT


    Bye!
    - ----
    Michael Reifenberger
    Plaut Software GmbH, R/3 Basis

    ------------------------------
  • The Hermit Hacker at Jul 3, 1997 at 12:12 am

    On Tue, 1 Jul 1997, Bruce Momjian wrote:

    Are we still scheduled for a 6.1p1 release?

    We are continuing to get inter-platform endian bug reports, and missing
    ENDIAN define bug reports, and we have fixed a few latent bugs.

    I think it is worth while to generate an official 6.1p1. I will do the
    HISTORY file.

    Don't wait for my psort() changes. They are not that important, and I
    am still reading Knuth to make sure I have all the areas covered.
    I'm sort of curious as to what sort of criteria we are looking at
    here? Since we do have the ENDIAN bugs still existing, we should wait for those
    to be fixed, no? But, do we introduce other changes in the meantime, so long
    as they don't force a dump/reload?

    Then again, with the current pgdump_all, my personal opinion is that
    doing a dump/reload is no longer an issue...

    If the developers are careful enough (and there are only a very select
    few that can even commit changes), we should be able to safely add features
    to the current source tree, without restricting a v6.1p1 release. ie. if
    someone has features to add, submit the patch...if the 'core developers'
    agree to include it, great...but please make sure your patch has been tested
    both before, and after, so that a v6.1p1 release is safe, and can be created
    at any time...

    Marc G. Fournier
    Systems Administrator @ hub.org
    primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

    ------------------------------
  • Thomas G. Lockhart at Jul 3, 1997 at 2:33 am

    I'm sort of curious as to what sort of criteria we are looking at
    here? Since we do have the ENDIAN bugs still existing, we should wait for those
    to be fixed, no? But, do we introduce other changes in the meantime, so long
    as they don't force a dump/reload?
    I think that the reported problems with v6.1 and the fixes already in
    the source tree warrant a full tar-file release of v6.1.1 (or whatever
    the right name would be).

    The only reported endian problems are for AIX/3.2.5 (no problems with
    AIX/4.1) and there are ripple effects with Frank Dana's proposed
    solution for 3.2.5 (since he adds an include file which may damage other
    ports).

    Reiner Buehl <reiner@asta.va.fh-ulm.de> reports problems with plain v6.1
    and HPUX/9.04, but Tatsuo Ishii <t-ishii@sra.co.jp> reports good success
    with HPUX/9.03 and he also contributed the endian patches.

    How about if we freeze the tree (now? or at a fixed date as we have with
    previous releases) and put out a full patched release. Frank can
    encapsulate his AIX/3.2.5 fixes into an ancillary patch file which can
    be applied as a one-liner and which won't damage other ports since it
    won't be applied for them. There will plenty of time to understand AIX
    for v6.2 :(

    Tatsuo's endian patches were tested on 3 or 4 platforms by him, and
    others have had time to try them out. We haven't had any reports of
    problems (other than AIX/3.2.5; remember that AIX/4.1 was reported to be
    a fairly clean install).

    I think that developers have been holding off on making major
    improvements or additions (I know I have) because they don't want to
    jeopardize a patch release.

    - Tom

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

    End of hackers-digest V1 #408
    *****************************
  • Gerhard Reithofer at Jul 3, 1997 at 9:35 am
    Hi Hackers,

    On Thu, 3 Jul 1997, Thomas G. Lockhart wrote:
    ... CUT ...
    Tatsuo's endian patches were tested on 3 or 4 platforms by him, and
    others have had time to try them out. We haven't had any reports of
    problems (other than AIX/3.2.5; remember that AIX/4.1 was reported to be
    a fairly clean install).
    ... CUT ...

    IMHO that's incorrect!

    The ENDIAN bug comes up when MIXING little-endian AND big-endian machines,
    independant from platforms and versions. It gets hidden on ONE platform,
    cause the "incorrect" byte order input will be "incorrect" changed back on
    the same platform - as stated in my earlier posting!

    It's present in AIX 4, even when AIX 4 compiles and works with AIX
    machines. But you cannot e. g. connect to a little-endian Intel-Linux
    machine.

    Cheers,
    Gerhard

    +------------------+ +--- gerhardr@tech-edv.co.at ----+
    T.B.Reithofer \ Gerhard | Technical Sofware Developement |
    Staatsbahnstr. 100 \ Reithofer | CAD/CAM/CAE/CAQ/CAP +----------+
    A-2136 Laa/Thaya +----------+ Mechanical CAD +----+
    Tel +43-2522/8726, Fax +43-2522/87268 +---------+
    +---------------------------------------+

    ------------------------------
  • Andrew Martin at Jul 3, 1997 at 10:43 am

    On Tue, 1 Jul 1997, Bruce Momjian wrote:
    Are we still scheduled for a 6.1p1 release?

    We are continuing to get inter-platform endian bug reports, and missing
    ENDIAN define bug reports, and we have fixed a few latent bugs.

    I think it is worth while to generate an official 6.1p1. I will do the
    HISTORY file.

    Don't wait for my psort() changes. They are not that important, and I
    am still reading Knuth to make sure I have all the areas covered.
    I'm sort of curious as to what sort of criteria we are looking at
    here? Since we do have the ENDIAN bugs still existing, we should wait for those
    to be fixed, no? But, do we introduce other changes in the meantime, so long
    as they don't force a dump/reload?
    I would say it should only include bug fixes and maybe some features
    which are absolutely trivial to add (like the ~/.psqlrc file) and then
    preferably not backend changes.

    Otherwise we are in danger of needing a V6.1p2


    Andrew
    - ----------------------------------------------------------------------------
    Dr. Andrew C.R. Martin University College London
    EMAIL: (Work) martin@biochem.ucl.ac.uk (Home) andrew@stagleys.demon.co.uk
    URL: http://www.biochem.ucl.ac.uk/~martin
    Tel: (Work) +44(0)171 419 3890 (Home) +44(0)1372 275775

    ------------------------------
  • Thomas G. Lockhart at Jul 3, 1997 at 1:53 pm

    Gerhard Reithofer wrote:
    On Thu, 3 Jul 1997, Thomas G. Lockhart wrote:
    ... CUT ...
    Tatsuo's endian patches were tested on 3 or 4 platforms by him, and
    others have had time to try them out. We haven't had any reports of
    problems (other than AIX/3.2.5; remember that AIX/4.1 was reported to be
    a fairly clean install).
    ... CUT ...
    IMHO that's incorrect!
    The ENDIAN bug comes up when MIXING little-endian AND big-endian machines,
    independant from platforms and versions. It gets hidden on ONE platform,
    cause the "incorrect" byte order input will be "incorrect" changed back on
    the same platform - as stated in my earlier posting!
    We understand that point. Have you actually tested the patches released
    a few days ago? They are in

    ftp://postgresql.org/pub/6.2/postgresql-v6.1-chngs-p1.tar.gz
    It's present in AIX 4, even when AIX 4 compiles and works with AIX
    machines. But you cannot e. g. connect to a little-endian Intel-Linux
    machine.
    from Tatsuo's mail dated 1997-06-24:
    (the patch) worked on many platforms including Linux/Intel,
    Linux/PPC, SunOS, 386-Solaris and so on.
    The various versions of AIX have _dominated_ the porting e-mail traffic
    the last few weeks. Does anyone have any indications that Tatsuo's
    patches do not fix the endian problems for non-AIX systems? He clearly
    tested on many platforms.

    Tatsuo, could you please describe the mix of machines you tested as
    servers and as clients? There is some uncertainty that all permutations
    of little- and big-endian clients and servers are functioning, but I
    suspect that your tests covered all combinations. TIA

    - Tom

    ------------------------------
  • Frank Dana at Jul 3, 1997 at 2:10 pm

    With Shakespearian flourish, "Thomas G. Lockhart" writes:
    I'm sort of curious as to what sort of criteria we are looking at
    here? Since we do have the ENDIAN bugs still existing, we should wait for
    those
    to be fixed, no? But, do we introduce other changes in the meantime, so lo
    ng
    as they don't force a dump/reload?
    I think that the reported problems with v6.1 and the fixes already in
    the source tree warrant a full tar-file release of v6.1.1 (or whatever
    the right name would be).

    The only reported endian problems are for AIX/3.2.5 (no problems with
    AIX/4.1) and there are ripple effects with Frank Dana's proposed
    solution for 3.2.5 (since he adds an include file which may damage other
    ports).
    And they don't work. The backend hangs trying to run the boolean regress-
    test. (Which I'm sure is only because it's the first one.) 8)

    I assume it's because there's some other function that consumes ENDIAN
    but not machine.h -- and the FOO_ENDIAN defines are respresented
    differently in postgres.h and AIX's machine.h. <sigh> That's what I
    get for rushing into patches -- as soon as I stopped coding and started
    thinking, I realized there was a good chance the patches would create
    other problems with ENDIAN representation on AIX 3.2.5.

    What if we moved the FOO_ENDIAN defines to include/ports/bar.h? Then we
    could put the proper logic in aix.h to deal with 3.2.5 vs 4.1 without
    mucking up the other ports' include files. It seems to make sense,
    actually -- endianness really a "machine-defined" thing, ripe for
    placement in the port-specific include files.

    I checked, and 4.1 also has ENDIAN defines in sys/machine.h. So
    ports/aix.h could simply include sys/machine.h where other ports
    do ENDIAN defines.

    -Frank

    - --
    Frank R. Dana, Jr. Senior Associate Programmer
    danaf@ans.net ANS Communications
    (914) 789-5449 100 Clearbrook Rd. Elmsford, NY 10523
    Pager: 800-946-4646 pin# 1420717

    ------------------------------
  • Frank Dana at Jul 3, 1997 at 3:24 pm

    With Shakespearian flourish, Frank Dana writes:
    [My ENDIAN patches for AIX 3.2.5]
    And they don't work. The backend hangs trying to run the boolean regress-
    test. (Which I'm sure is only because it's the first one.) 8)

    I checked, and 4.1 also has ENDIAN defines in sys/machine.h. So
    ports/aix.h could simply include sys/machine.h where other ports
    do ENDIAN defines.
    Confirmed. When I reverted to 6.1p1 sources, ripped all reference to
    ENDIAN from postgres.h, and #included <sys/machine.h> in
    include/ports/aix.h, everything worked fine and the regression tests
    ran A-OK. (Ignoring the standard errors. Any objections to me submitting
    patches that fix the obvious ones, like the incorrect error text in
    int[24], oidint[24], etc?)

    I'd definitely like to request that anything involving endianness be
    kept out of postgres.h and placed in include/ports/foo.h. For aix.h,
    the "accepted AIX method" for dealing with endianness is to simply
    #include <sys/machine.h> and should be used in place of the current
    set of #ifdefs and HAVE_ENDIAN_H checks. (Even if someone has an AIX
    system that has endian.h, it shouldn't be used -- as soon as
    <netinet/in.h> is included, it will bring <system/machine.h> with it
    and conflict.)

    Given this small change, 6.1p1 on AIX looks good. It complies
    cleanly, and the regression tests run with only a few failures.
    The DST handling that someone else reported in abstime still
    seems to be there (where results reports 00:xx:xx PDT where
    expected wants 23:xx:xx PST the previous day) -- but at least
    the time values themselves are correct.

    -Frank

    - --
    Frank R. Dana, Jr. Senior Associate Programmer
    danaf@ans.net ANS Communications
    (914) 789-5449 100 Clearbrook Rd. Elmsford, NY 10523
    Pager: 800-946-4646 pin# 1420717

    ------------------------------
  • Tatsuo Ishii at Jul 4, 1997 at 2:20 am

    From Tatsuo's mail dated 1997-06-24:
    (the patch) worked on many platforms including Linux/Intel,
    Linux/PPC, SunOS, 386-Solaris and so on.
    The various versions of AIX have _dominated_ the porting e-mail traffic
    the last few weeks. Does anyone have any indications that Tatsuo's
    patches do not fix the endian problems for non-AIX systems? He clearly
    tested on many platforms.

    Tatsuo, could you please describe the mix of machines you tested as
    servers and as clients? There is some uncertainty that all permutations
    of little- and big-endian clients and servers are functioning, but I
    suspect that your tests covered all combinations. TIA

    - Tom
    Last night I tested following combinations by myself again.

    o SunOS 4.1.4/gcc 2.7.1(SunOS patch applied)

    o MkLinux DR2.1 Update2+shared lib support/gcc 2.7.2.1(MkLinux patch applied)

    o Linux 2.0.29/Intel Pentium/gcc 2.7.2.1

    Among these, Linux 2.0.29 is the only Little endian machine.
    I checked all of flowing combinations:

    Client Server
    - ----------------------
    Linux MkLinux
    Linux SunOS
    MkLinux Linux
    MkLinux SunOS
    SunOS Linux
    SunOS MkLinux

    Other platforms have been tested by our local user groups. I hope
    additional reports will come soon.
    - ---
    Tatsuo Ishii
    t-ishii@sra.co.jp

    ------------------------------
  • The Hermit Hacker at Jul 4, 1997 at 2:41 am

    On Thu, 3 Jul 1997, Andrew Martin wrote:
    On Tue, 1 Jul 1997, Bruce Momjian wrote:

    Are we still scheduled for a 6.1p1 release?

    We are continuing to get inter-platform endian bug reports, and missing
    ENDIAN define bug reports, and we have fixed a few latent bugs.

    I think it is worth while to generate an official 6.1p1. I will do the
    HISTORY file.

    Don't wait for my psort() changes. They are not that important, and I
    am still reading Knuth to make sure I have all the areas covered.
    I'm sort of curious as to what sort of criteria we are looking at
    here? Since we do have the ENDIAN bugs still existing, we should wait for those
    to be fixed, no? But, do we introduce other changes in the meantime, so long
    as they don't force a dump/reload?
    I would say it should only include bug fixes and maybe some features
    which are absolutely trivial to add (like the ~/.psqlrc file) and then
    preferably not backend changes.

    Otherwise we are in danger of needing a V6.1p2
    'features that are absolutely trivial to add' will not require a p2
    release...p2 is *only* meant as a bug fix release. If we happen to be able
    to get a couple of 'trivial features' added, all the better, but they are
    not required

    Marc G. Fournier
    Systems Administrator @ hub.org
    primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

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

    End of hackers-digest V1 #409
    *****************************
  • Frank Dana at Jul 4, 1997 at 3:53 am

    With Shakespearian flourish, Tatsuo Ishii writes:

    Tatsuo, could you please describe the mix of machines you tested as
    servers and as clients? There is some uncertainty that all permutations
    of little- and big-endian clients and servers are functioning, but I
    suspect that your tests covered all combinations. TIA
    Last night I tested following combinations by myself again.

    o SunOS 4.1.4/gcc 2.7.1(SunOS patch applied)
    o MkLinux DR2.1 Update2+shared lib support/gcc 2.7.2.1(MkLinux patch applied)
    o Linux 2.0.29/Intel Pentium/gcc 2.7.2.1
    I've tested our Pentium BSDi boxes, AIX 3.2.5 RS/6000s (with my ENDIAN
    fixes applied) and Solaris 2.5.1 Sparcs. The BSDi and AIX boxes have
    no trouble talking to each other (despite the endianness difference)
    but the Solaris box refuses to talk to either. CREATE and INSERT calls
    are fine (from AIX or BSDi to a Solaris backend, or from Solaris to
    either), but anything that displays a table (SELECT, \d) causes the
    client to hang. This was a last-minute test as I was running out to
    dinner, so I haven't begun to debug it yet, but it seems to be a problem.
    I definitely tested all 6 combinations and found Solaris/Sparc to be the
    breaking factor.

    I'll test between two Sparc boxes to make sure it isn't the network
    code itself that's somehow letting me down. Haven't tried that yet.

    -Frank

    ------------------------------
  • Tatsuo Ishii at Jul 4, 1997 at 5:22 am
    Regarding the endian patch, here are additional reports. I have just
    installed 6.1+endian patch to an Ultra Sparc(Solaris 2.5.1/gcc 2.7.0).
    Last night I tested following combinations by myself again.

    o SunOS 4.1.4/gcc 2.7.1(SunOS patch applied)

    o MkLinux DR2.1 Update2+shared lib support/gcc 2.7.2.1(MkLinux patch applied)

    o Linux 2.0.29/Intel Pentium/gcc 2.7.2.1
    I confirmed the Ultra worked with any of them above too.

    Also, Eiji Matsumoto (ematsu@pfu.co.jp) has reported to me that
    following combination worked:

    FreeBSD-2.2.2-RELEASE (i486 100MHz) /gcc 2.7.2.1
    Solaris2.5.1 (SuperSparc) / gcc 2.7.2.2
    - ---
    Tatsuo Ishii
    t-ishii@sra.co.jp

    ------------------------------
  • Andrew Martin at Jul 7, 1997 at 8:46 am

    On Thu, 3 Jul 1997, Andrew Martin wrote:
    On Tue, 1 Jul 1997, Bruce Momjian wrote:
    I would say it should only include bug fixes and maybe some features
    which are absolutely trivial to add (like the ~/.psqlrc file) and then
    preferably not backend changes.

    Otherwise we are in danger of needing a V6.1p2
    'features that are absolutely trivial to add' will not require a p2
    release...p2 is *only* meant as a bug fix release. If we happen to be able
    to get a couple of 'trivial features' added, all the better, but they are
    not required

    Marc G. Fournier
    My point exactly! If anything is added to V6.1p1 which is *not* trivial
    then bugs could be introduced and we therefore would require a p2.

    We don't want that to happen as I'm sure people want to start getting on
    with 6.2


    Andrew

    - ----------------------------------------------------------------------------
    Dr. Andrew C.R. Martin University College London
    EMAIL: (Work) martin@biochem.ucl.ac.uk (Home) andrew@stagleys.demon.co.uk
    URL: http://www.biochem.ucl.ac.uk/~martin
    Tel: (Work) +44(0)171 419 3890 (Home) +44(0)1372 275775

    ------------------------------
  • Frank Dana at Jul 7, 1997 at 10:03 pm

    I wrote:
    I've tested our Pentium BSDi boxes, AIX 3.2.5 RS/6000s (with my ENDIAN
    fixes applied) and Solaris 2.5.1 Sparcs. The BSDi and AIX boxes have
    no trouble talking to each other (despite the endianness difference)
    but the Solaris box refuses to talk to either. CREATE and INSERT calls
    are fine (from AIX or BSDi to a Solaris backend, or from Solaris to
    either), but anything that displays a table (SELECT, \d) causes the
    client to hang. This was a last-minute test as I was running out to
    dinner, so I haven't begun to debug it yet, but it seems to be a problem.
    I definitely tested all 6 combinations and found Solaris/Sparc to be the
    breaking factor.
    Hrm. Or, rather, ONE Sparc/Solaris box. I compiled on another box and
    transferred the binaries over, and it works fine. It might be compiler
    versions (2.7.2.1 on the working box, vs 2.7.2 on the non-working one),
    but I've successfully chatted between every combination of BSDi,
    AIX 3.2.5, and Sparc/Solaris at this point.

    -Frank

    - --
    Frank R. Dana, Jr. Senior Associate Programmer
    danaf@ans.net ANS Communications
    (914) 789-5449 100 Clearbrook Rd. Elmsford, NY 10523
    Pager: 800-946-4646 pin# 1420717

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedJul 1, '97 at 2:04p
activeJul 7, '97 at 10:03p
posts17
users9
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase