From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [COMMITTERS] pgsql: Upgrade to Autoconf 2.69 |
Date: | 2013-12-29 18:05:29 |
Message-ID: | 14711.1388340329@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
I wrote:
> Perhaps though we should override Autoconf's setting of
> _DARWIN_USE_64_BIT_INODE, if we can do that easily? It's clearly
> not nearly as problem-free on 10.5 as the Autoconf boys believe,
> and it's already enabled by default on the release series where it
> does work.
I looked into this and found that _DARWIN_USE_64_BIT_INODE is being turned
on by AC_SYS_LARGEFILE. Quite aside from the wisdom of doing this at all,
it's got nothing to do with the advertised purpose of that macro: the
width of inode_t would affect how many files you can put on one
filesystem, not how large the individual files are. I don't think that is
something that we need to concern ourselves with enabling when it's not
the platform default. And just to add insult to injury, the
implementation technique is such that the #define gets put into
pg_config.h unconditionally, even if AC_SYS_LARGEFILE isn't executed by
the configure script!
So IMO this is brain-dead in at least three different ways, and I've
pushed a patch to revert it.
We still need to address the other issues enumerated in my previous
message, but this should be enough to get buildfarm member locust
happy again.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2013-12-29 21:24:27 | pgsql: Don't attempt to limit target database for pg_restore. |
Previous Message | Tom Lane | 2013-12-29 17:58:17 | pgsql: Undo autoconf 2.69's attempt to #define _DARWIN_USE_64_BIT_INODE |
From | Date | Subject | |
---|---|---|---|
Next Message | Sergey Konoplev | 2013-12-29 21:22:20 | Re: Polymorphic function calls |
Previous Message | Tom Lane | 2013-12-29 17:38:00 | Re: [BUG FIX] Version number expressed in octal form by mistake |