- May 02, 2015
-
-
Peter Eisentraut authored
-
Peter Eisentraut authored
Apparently, looking for an appropriately named file doesn't work on some older versions, so put the back the explicit platform detection.
-
Peter Eisentraut authored
For building PL/Perl, PL/Python, and PL/Tcl, we need a shared library of libperl, libpython, and libtcl, respectively. Previously, this was checked in the makefiles, skipping the PL build with a warning if no shared library was available. Now this is checked in configure, with an error if no shared library is available. The previous situation arose because in the olden days, the configure options --with-perl, --with-python, and --with-tcl controlled whether frontend interfaces for those languages would be built. The procedural languages were added later, and shared libraries were often not available in the beginning. So it was decided skip the builds of the procedural languages in those cases. The frontend interfaces have since been removed from the tree, and shared libraries are now available most of the time, so that setup makes much less sense now. Also, the new setup allows contrib modules and pgxs users to rely on the respective PLs being available based on configure flags.
-
- Apr 14, 2015
-
-
Heikki Linnakangas authored
On gcc and clang, the _mm_crc32_u8 and _mm_crc32_u64 intrinsics are not defined at all, when not building with -msse4.2. But on icc, they are. So we cannot assume that if those intrinsics are defined, we can always use them safely, we might still need the runtime check. To fix, check if the __SSE_4_2__ preprocessor symbol is defined. That's supposed to be defined only when the compiler is targeting a processor that has SSE 4.2 support. Per buildfarm members fulmar and okapi.
-
Heikki Linnakangas authored
Modern x86 and x86-64 processors with SSE 4.2 support have special instructions, crc32b and crc32q, for calculating CRC-32C. They greatly speed up CRC calculation. Whether the instructions can be used or not depends on the compiler and the target architecture. If generation of SSE 4.2 instructions is allowed for the target (-msse4.2 flag on gcc and clang), use them. If they are not allowed by default, but the compiler supports the -msse4.2 flag to enable them, compile just the CRC-32C function with -msse4.2 flag, and check at runtime whether the processor we're running on supports it. If it doesn't, fall back to the slicing-by-8 algorithm. (With the common defaults on current operating systems, the runtime-check variant is what you get in practice.) Abhijit Menon-Sen, heavily modified by me, reviewed by Andres Freund.
-
- Apr 05, 2015
-
-
Tom Lane authored
Considering the number of cases in which "unused" command line arguments are silently ignored by compilers, it's fairly astonishing that anybody thought this warning was useful; it's certainly nothing but an annoyance when building Postgres. One such case is that neither gcc nor clang complain about unrecognized -Wno-foo switches, making it more difficult to figure out whether the switch does anything than one could wish. Back-patch to 9.3, which is as far back as the patch applies conveniently (we'd have to back-patch PGAC_PROG_CC_VAR_OPT to go further, and it doesn't seem worth that).
-
- Mar 20, 2015
-
-
Andres Freund authored
We will, for the foreseeable future, not expose 128 bit datatypes to SQL. But being able to use 128bit math will allow us, in a later patch, to use 128bit accumulators for some aggregates; leading to noticeable speedups over using numeric. So far we only detect a gcc/clang extension that supports 128bit math, but no 128bit literals, and no *printf support. We might want to expand this in the future to further compilers; if there are any that that provide similar support. Discussion: 544BB5F1.50709@proxel.se Author: Andreas Karlsson, with significant editorializing by me Reviewed-By: Peter Geoghegan, Oskari Saarenmaa
-
- Mar 15, 2015
-
- Mar 14, 2015
-
-
Tom Lane authored
Since commit ba7c5975, port/dirmod.c has contained only Windows-specific functions. Most platforms don't seem to mind uselessly building an empty file, but OS X for one issues warnings. Hence, treat dirmod.c as a Windows-specific file selected by configure rather than one that's always built. We can revert this change if dirmod.c ever gains any non-Windows functionality again. Back-patch to 9.4 where the mentioned commit appeared.
-
- Feb 10, 2015
-
-
Heikki Linnakangas authored
This speeds up WAL generation and replay. The new algorithm is significantly faster with large inputs, like full-page images or when inserting wide rows. It is slower with tiny inputs, i.e. less than 10 bytes or so, but the speedup with longer inputs more than make up for that. Even small WAL records at least have 24 byte header in the front. The output is identical to the current byte-at-a-time computation, so this does not affect compatibility. The new algorithm is only used for the CRC-32C variant, not the legacy version used in tsquery or the "traditional" CRC-32 used in hstore and ltree. Those are not as performance critical, and are usually only applied over small inputs, so it seems better to not carry around the extra lookup tables to speed up those rare cases. Abhijit Menon-Sen
-
- Jan 14, 2015
-
-
Tom Lane authored
Previously, configure would add any switches that it chose of its own accord to the end of the user-specified CFLAGS string. Since most compilers process these left-to-right, this meant that configure's choices would override the user-specified flags in case of conflicts. We'd rather that worked the other way around, so adjust the logic to put the user's string at the end not the beginning. There does not seem to be a need for a similar behavior change for CPPFLAGS or LDFLAGS: in those, the earlier switches tend to win (think -I or -L behavior) so putting the user's string at the front is fine. Backpatch to 9.4 but not earlier. I'm not planning to run buildfarm member guar on older branches, and it seems a bit risky to change this behavior in long-stable branches.
-
- Jan 11, 2015
-
-
Tom Lane authored
We had code that supposed that some platforms might offer a nonstandard version of getpwuid_r() with only four arguments. However, the 5-argument definition has been standardized at least since the Single Unix Spec v2, which is our normal reference for what's portable across all Unix-oid platforms. (What's more, this wasn't the only pre-standardization version of getpwuid_r(); my old HPUX 10.20 box has still another signature.) So let's just get rid of the now-useless configure step.
-
- Jan 08, 2015
-
-
Noah Misch authored
Darwin --enable-nls builds use a substitute setlocale() that may start a thread. Buildfarm member orangutan experienced BackendList corruption on account of different postmaster threads executing signal handlers simultaneously. Furthermore, a multithreaded postmaster risks undefined behavior from sigprocmask() and fork(). Emit LOG messages about the problem and its workaround. Back-patch to 9.0 (all supported versions).
-
- Jan 06, 2015
-
-
Bruce Momjian authored
Backpatch certain files through 9.0
-
- Nov 23, 2014
-
-
Noah Misch authored
This eliminates gobs of "unrecognized format function type" warnings under MinGW compilers predating GCC 4.4.
-
- Nov 02, 2014
-
-
Peter Eisentraut authored
Don't skip the TAP tests anymore when IPC::Run is not found. This will fail normally now.
-
- Oct 25, 2014
-
-
Andres Freund authored
Discussion: 20140925133459.GB9633@alap3.anarazel.de Author: Oskari Saarenmaa
-
- Oct 21, 2014
-
-
Peter Eisentraut authored
Building the documentation with XSLT does not check the DTD, like a DSSSL build would. One can often get away with having invalid XML, but the stylesheets might then create incorrect output, as they are not designed to handle that. Therefore, check the validity of the XML against the DTD, using xmllint, during the build. Add xmllint detection to configure, and add some documentation. xmllint comes with libxml2, which is already in use, but it might be in a separate package, such as libxml2-utils on Debian. Reviewed-by:
Fabien COELHO <coelho@cri.ensmp.fr>
-
- Sep 25, 2014
-
-
Andres Freund authored
Several upcoming performance/scalability improvements require atomic operations. This new API avoids the need to splatter compiler and architecture dependent code over all the locations employing atomic ops. For several of the potential usages it'd be problematic to maintain both, a atomics using implementation and one using spinlocks or similar. In all likelihood one of the implementations would not get tested regularly under concurrency. To avoid that scenario the new API provides a automatic fallback of atomic operations to spinlocks. All properties of atomic operations are maintained. This fallback - obviously - isn't as fast as just using atomic ops, but it's not bad either. For one of the future users the atomics ontop spinlocks implementation was actually slightly faster than the old purely spinlock using implementation. That's important because it reduces the fear of regressing older platforms when improving the scalability for new ones. The API, loosely modeled after the C11 atomics support, currently provides 'atomic flags' and 32 bit unsigned integers. If the platform efficiently supports atomic 64 bit unsigned integers those are also provided. To implement atomics support for a platform/architecture/compiler for a type of atomics 32bit compare and exchange needs to be implemented. If available and more efficient native support for flags, 32 bit atomic addition, and corresponding 64 bit operations may also be provided. Additional useful atomic operations are implemented generically ontop of these. The implementation for various versions of gcc, msvc and sun studio have been tested. Additional existing stub implementations for * Intel icc * HUPX acc * IBM xlc are included but have never been tested. These will likely require fixes based on buildfarm and user feedback. As atomic operations also require barriers for some operations the existing barrier support has been moved into the atomics code. Author: Andres Freund with contributions from Oskari Saarenmaa Reviewed-By: Amit Kapila, Robert Haas, Heikki Linnakangas and Álvaro Herrera Discussion: CA+TgmoYBW+ux5-8Ja=Mcyuy8=VXAnVRHp3Kess6Pn3DMXAPAEA@mail.gmail.com, 20131015123303.GH5300@awork2.anarazel.de, 20131028205522.GI20248@awork2.anarazel.de
-
- Sep 14, 2014
-
-
Peter Eisentraut authored
Instead of just erroring out when a tool is missing, wrap the call with the "missing" script that we are already using for bison, flex, and perl, so that the users get a useful error message.
-
- Aug 29, 2014
-
-
Noah Misch authored
Commit a16bac36 let "configure" detect the system getaddrinfo() when building under 64-bit MinGW-w64. However, src/include/port/win32/sys/socket.h assumes all native Windows configurations use our replacement. This change placates buildfarm member jacana until we establish a plan for getaddrinfo() on Windows.
-
- Aug 21, 2014
-
-
Heikki Linnakangas authored
We have had INT64_FORMAT and UINT64_FORMAT for a long time, but that's not good enough if you want something more exotic, like "%20lld". Abhijit Menon-Sen, per Andres Freund's suggestion.
-
- Aug 11, 2014
-
-
Heikki Linnakangas authored
This refactoring is in preparation for adding support for other SSL implementations, with no user-visible effects. There are now two #defines, USE_OPENSSL which is defined when building with OpenSSL, and USE_SSL which is defined when building with any SSL implementation. Currently, OpenSSL is the only implementation so the two #defines go together, but USE_SSL is supposed to be used for implementation-independent code. The libpq SSL code is changed to use a custom BIO, which does all the raw I/O, like we've been doing in the backend for a long time. That makes it possible to use MSG_NOSIGNAL to block SIGPIPE when using SSL, which avoids a couple of syscall for each send(). Probably doesn't make much performance difference in practice - the SSL encryption is expensive enough to mask the effect - but it was a natural result of this refactoring. Based on a patch by Martijn van Oosterhout from 2006. Briefly reviewed by Alvaro Herrera, Andreas Karlsson, Jeff Janes.
-
- Jul 26, 2014
-
-
Noah Misch authored
This restores the style of keeping configure.in free of AC_DEFUN. Per gripe from Tom Lane.
-
- Jul 22, 2014
-
-
Noah Misch authored
With OpenLDAP versions 2.4.24 through 2.4.31, inclusive, PostgreSQL backends can crash at exit. Raise a warning during "configure" based on the compile-time OpenLDAP version number, and test the crash scenario in the dblink test suite. Back-patch to 9.0 (all supported versions).
-
- Jul 15, 2014
-
-
Magnus Hagander authored
Mingw uses a different header file than msvc, so we don't get the hardcoded value, so we need the configure test to run.
-
Magnus Hagander authored
Apparently we still build against OpenSSL so old that it doesn't have this function, so add an autoconf check for it to make the buildfarm happy. If the function doesn't exist, always return that compression is disabled, since presumably the actual compression functionality is always missing. For now, hardcode the function as present on MSVC, since we should hopefully be well beyond those old versions on that platform.
-
Magnus Hagander authored
ws2_32 is the new version of the library that should be used, as it contains the require functionality from wsock32 as well as some more (which is why some binaries were already using ws2_32). Michael Paquier, reviewed by MauMau
-
- Jul 01, 2014
-
-
Tom Lane authored
Almost ten years ago, commit e48322a6 broke the logic in ACX_PTHREAD by looping through all the possible flags rather than stopping with the first one that would work. This meant that $acx_pthread_ok was no longer meaningful after the loop; it would usually be "no", whether or not we'd found working thread flags. The reason nobody noticed is that Postgres doesn't actually use any of the symbols set up by the code after the loop. Rather than complicate things some more to make it work as designed, let's just remove all that dead code, and thereby save a few cycles in each configure run.
-
- Jun 28, 2014
-
-
Andres Freund authored
Support for running postgres on Alpha hasn't been tested for a long while. Due to Alpha's uniquely lax cache coherency model it's a hard to develop for platform (especially blindly!) and thought to be unlikely to currently work correctly. As Alpha is the only supported architecture for Tru64 drop support for it as well. Tru64's support has ended 2012 and it has been in maintenance-only mode for much longer. Also remove stray references to __ksr__ and ultrix defines.
-
- Jun 14, 2014
-
-
Noah Misch authored
This function is pervasive on free software operating systems; import NetBSD's implementation. Back-patch to 8.4, like the commit that will harness it.
-
- Jun 11, 2014
-
-
Tom Lane authored
Let the hacking begin ...
-
- May 28, 2014
-
-
Tom Lane authored
Allow the contrib/uuid-ossp extension to be built atop any one of these three popular UUID libraries. (The extension's name is now arguably a misnomer, but we'll keep it the same so as not to cause unnecessary compatibility issues for users.) We would not normally consider a change like this post-beta1, but the issue has been forced by our upgrade to autoconf 2.69, whose more rigorous header checks are causing OSSP's header files to be rejected on some platforms. It's been foreseen for some time that we'd have to move away from depending on OSSP UUID due to lack of upstream maintenance, so this is a down payment on that problem. While at it, add some simple regression tests, in hopes of catching any major incompatibilities between the three implementations. Matteo Beccati, with some further hacking by me
-
- May 11, 2014
-
- May 05, 2014
-
-
Heikki Linnakangas authored
It's easy to forget using SYSTEMQUOTEs when constructing command strings for system() or popen(). Even if we fix all the places missing it now, it is bound to be forgotten again in the future. Introduce wrapper functions that do the the extra quoting for you, and get rid of SYSTEMQUOTEs in all the callers. We previosly used SYSTEMQUOTEs in all the hard-coded command strings, and this doesn't change the behavior of those. But user-supplied commands, like archive_command, restore_command, COPY TO/FROM PROGRAM calls, as well as pgbench's \shell, will now gain an extra pair of quotes. That is desirable, but if you have existing scripts or config files that include an extra pair of quotes, those might need to be adjusted. Reviewed by Amit Kapila and Tom Lane
-
- Apr 15, 2014
-
-
Peter Eisentraut authored
Reviewed-by:
Pavel Stěhule <pavel.stehule@gmail.com> Reviewed-by:
Erik Rijkers <er@xs4all.nl>
-
- Feb 23, 2014
-
-
Peter Eisentraut authored
The comment added by ed011d97 used #, which means it gets copied into configure, but it doesn't make sense there. So use dnl, which gets dropped when creating configure.
-
- Jan 23, 2014
-
-
Tom Lane authored
Since C99, it's been standard for printf and friends to accept a "z" size modifier, meaning "whatever size size_t has". Up to now we've generally dealt with printing size_t values by explicitly casting them to unsigned long and using the "l" modifier; but this is really the wrong thing on platforms where pointers are wider than longs (such as Win64). So let's start using "z" instead. To ensure we can do that on all platforms, teach src/port/snprintf.c to understand "z", and add a configure test to force use of that implementation when the platform's version doesn't handle "z". Having done that, modify a bunch of places that were using the unsigned-long hack to use "z" instead. This patch doesn't pretend to have gotten everyplace that could benefit, but it catches many of them. I made an effort in particular to ensure that all uses of the same error message text were updated together, so as not to increase the number of translatable strings. It's possible that this change will result in format-string warnings from pre-C99 compilers. We might have to reconsider if there are any popular compilers that will warn about this; but let's start by seeing what the buildfarm thinks. Andres Freund, with a little additional work by me
-
- Jan 19, 2014
-
-
Magnus Hagander authored
krb5 has been deprecated since 8.3, and the recommended way to do Kerberos authentication is using the GSSAPI authentication method (which is still fully supported). libpq retains the ability to identify krb5 authentication, but only gives an error message about it being unsupported. Since all authentication is initiated from the backend, there is no need to keep it at all in the backend.
-
- Jan 07, 2014
-
-
Bruce Momjian authored
Update all files in head, and files COPYRIGHT and legal.sgml in all back branches.
-