Re: PostgreSQL 11 beta1 on AIX 7.2 : 2 failures in 32bit mode

On Thu, May 31, 2018 at 07:23:57PM -0400, Tom Lane wrote:
> Noah Misch <noah@leadboat.com> writes:
> > On Thu, May 31, 2018 at 10:28:12AM -0400, Tom Lane wrote:
> >> I wondered why the existing 32-bit AIX buildfarm machines aren't showing
> >> problems, but looking closer at them, they are manually forcing
> >> _LARGE_FILES, which probably is masking things:
> >>     'config_env' => {
> >>     'CC' => 'wrap-gcc -D_THREAD_SAFE=1 -D_LARGE_FILES=1 -maix32',
> >> Noah, why'd you do that, and would you be willing to remove it?  IMO
> >> Postgres should work without that.
> 
> > I did that to work around a problem like the one articulated upthread.
> > Specifically, a 64-bit build w/ plpython failed:
> > ...
> > Today's "configure" test concludes that we don't need _LARGE_FILES, because
> > off_t is 64-bit ("long", specifically) in this configuration.  The trouble
> > arises when Python.h does cause _LARGE_FILES to be defined.
> 
> Ugh.  That's a pretty crummy decision on their part, although maybe there
> was no better alternative.
> 
> This does not seem like it explains Tony's problem with AIX 32-bit,
> though, as you'd think all concerned would agree _LARGE_FILES needs
> to be 1 in that case.

Yep.  I suspect _LARGE_FILES is orthogonal to $SUBJECT, which looks like a
problem with floating point ABI or possibly structure layout.  Since, as you
say, all code concerned wants 64-bit off_t at all times, I doubt _LARGE_FILES
would be the cause of a structure layout mismatch.

> > At the time I added the workaround, I scratched down these candidates for a
> > proper fix:
> 
> > 1. Add "configure" test to determine whether Python defines _LARGE_FILES.
> >    When it does, define it ourselves at the top of each Python-associated
> >    source file.
> 
> That would make aspects of our extension ABI dependent on whether one had
> configured with --enable-python, which would be surprising to say the
> least.

I don't think it would.  We use _LARGE_FILES anyway on 32-bit.  On 64-bit,
_LARGE_FILES boils down to s/long/long long/, which is a C API change but not
an ABI change.

> > 2. Define _LARGE_FILES unconditionally on AIX.  That is, adopt the workaround
> >    as permanent.
> 
> Perhaps.  I wonder though whether this is really an AIX-only problem.
> (In particular, I wonder whether Python.h is clobbering _FILE_OFFSET_BITS
> on other platforms.)  There's a comment in Autoconf's AC_SYS_LARGEFILE
> that suggests it is, but ...
> 
> > 3. Define _LARGE_FILES unconditionally.  This should be harmless, but I
> >    wouldn't tend to back-patch it.
> 
> It seems like variants of this issue should exist in all branches,
> so I'm not really happy with taking a fix we're scared to back-patch.
> If we were willing to do so, though, this might be OK.  Seems like there
> are three possibilities:
> * Defining _LARGE_FILES does something good, in which case we want it.
> * Defining _LARGE_FILES does nothing.
> * Defining _LARGE_FILES does something bad ... but it's hard to see
> how that could be.

Fair.  I'd be content about back-patching for AIX, because 100% of AIX
buildfarm animals already do this.  While I don't anticipate specific breakage
on other platforms, testing the _LARGE_FILES interpretation of every 64-bit
libc on the planet feels like a recipe for surprises.