Re: AIX support - alignment issues

Peter Geoghegan <pg@bowt.ie> writes:
> I tend to agree about dropping AIX. But I wonder if there is an
> argument against that proposal that doesn't rely on AIX being relevant
> to at least one user. Has supporting AIX ever led to the discovery of
> a bug that didn't just affect AIX?

Searching the commit log quickly finds

591e088dd

    datetime.c's parsing logic has assumed that strtod() will accept
    a string that looks like ".", which it does in glibc, but not on
    some less-common platforms such as AIX.

glibc's behavior is clearly not meeting the letter of the POSIX spec here.

a745b9365
    
    I'm not sure how we've managed not to notice this problem, but it
    seems to explain slow execution of the 017_shm.pl test script on AIX
    since commit 4fdbf9af5, which added a speculative "pg_ctl stop" with
    the idea of making real sure that the postmaster isn't there.  In the
    test steps that kill-9 and then restart the postmaster, it's possible
    to get past the initial signal attempt before kill() stops working
    for the doomed postmaster.  If that happens, pg_ctl waited till
    PGCTLTIMEOUT before giving up ... and the buildfarm's AIX members
    have that set very high.

Admittedly, this one is more about "slow" than about "AIX".

57b5a9646
    
    Most versions of tar are willing to overlook the missing terminator, but
    the AIX buildfarm animals were not. Fix by inventing a new kind of
    bbstreamer that just blindly adds a terminator, and using it whenever we
    don't parse the tar archive.

Another place where we failed to conform to relevant standards.    

b9b610577

    Fix ancient violation of zlib's API spec.
    
And another.

Now, it's certainly possible that AIX is the only surviving platform
that hasn't adopted bug-compatible-with-glibc interpretations of
POSIX.  But I think the standard is the standard, and we ought to
stay within it.  So I find value in these fixes.

			regards, tom lane