aboutsummaryrefslogtreecommitdiff
path: root/src/tools
Commit message (Collapse)AuthorAge
* Fix MVCC bug with prepared xact with subxacts on standbyHeikki Linnakangas2024-06-27
| | | | | | | | | | | | | | | | | | We did not recover the subtransaction IDs of prepared transactions when starting a hot standby from a shutdown checkpoint. As a result, such subtransactions were considered as aborted, rather than in-progress. That would lead to hint bits being set incorrectly, and the subtransactions suddenly becoming visible to old snapshots when the prepared transaction was committed. To fix, update pg_subtrans with prepared transactions's subxids when starting hot standby from a shutdown checkpoint. The snapshots taken from that state need to be marked as "suboverflowed", so that we also check the pg_subtrans. Backport to all supported versions. Discussion: https://www.postgresql.org/message-id/6b852e98-2d49-4ca1-9e95-db419a2696e0@iki.fi
* Remove redundant perl version checksAndrew Dunstan2024-06-26
| | | | | | | | | | | | | Commit 4c1532763a removed some redundant uses of 'use 5.008001;' in perl scripts, including in plperl's plc_perlboot.pl. Because it made other changes it wasn't backpatched. However, now this is causing a failure on back branches when built with bleeding edge perl. Therefore, backpatch just that part of it which removed those uses, from 15 all the way down to 9.2, which is the earliest version currently built in the buildfarm. per report from Alexander Lakhin Discussion: https://postgr.es/m/4cc2ee93-e03c-8e13-61ed-412e7e6ff19d@gmail.com
* Fix MSVC recipe for ecpg regression tests, redux.Tom Lane2024-04-19
| | | | | | | | Forgot to inject -DCMDLINESYM=123 ... Per buildfarm. Discussion: https://postgr.es/m/4cc4dc47-ca2b-4129-8784-db69b5f82777@dunslane.net
* Fix MSVC recipe for ecpg regression tests.Tom Lane2024-04-18
| | | | | | | | | | | While back-patching commit 6f0cef935, I forgot that the MSVC build scripts would also need adjustment in the back branches. This is a blind attempt at a fix, but it's basically copying nearby code so I think it will work. Per buildfarm (via Andrew Dunstan) Discussion: https://postgr.es/m/4cc4dc47-ca2b-4129-8784-db69b5f82777@dunslane.net
* Fix various issues with ALTER TEXT SEARCH CONFIGURATIONMichael Paquier2024-01-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit addresses a set of issues when changing token type mappings in a text search configuration when using duplicated token names: - ADD MAPPING would fail on insertion because of a constraint failure after inserting the same mapping. - ALTER MAPPING with an "overridden" configuration failed with "tuple already updated by self" when the token mappings are removed. - DROP MAPPING failed with "tuple already updated by self", like previously, but in a different code path. The code is refactored so the token names (with their numbers) are handled as a List with unique members rather than an array with numbers, ensuring that no duplicates mess up with the catalog inserts, updates and deletes. The list is generated by getTokenTypes(), with the same error handling as previously while duplicated tokens are discarded from the list used to work on the catalogs. Regression tests are expanded to cover much more ground for the cases fixed by this commit, as there was no coverage for the code touched in this commit. A bit more is done regarding the fact that a token name not supported by a configuration's parser should result in an error even if IF EXISTS is used in a DROP MAPPING clause. This is implied in the code but there was no coverage for that, and it was very easy to miss. These issues exist since at least their introduction in core with 140d4ebcb46e, so backpatch all the way down. Reported-by: Alexander Lakhin Author: Tender Wang, Michael Paquier Discussion: https://postgr.es/m/18310-1eb233c5908189c8@postgresql.org Backpatch-through: 12
* Use BIO_{get,set}_app_data instead of BIO_{get,set}_data.Tom Lane2023-11-28
| | | | | | | | | | | | | | | | | | | | | | We should have done it this way all along, but we accidentally got away with using the wrong BIO field up until OpenSSL 3.2. There, the library's BIO routines that we rely on use the "data" field for their own purposes, and our conflicting use causes assorted weird behaviors up to and including core dumps when SSL connections are attempted. Switch to using the approved field for the purpose, i.e. app_data. While at it, remove our configure probes for BIO_get_data as well as the fallback implementation. BIO_{get,set}_app_data have been there since long before any OpenSSL version that we still support, even in the back branches. Also, update src/test/ssl/t/001_ssltests.pl to allow for a minor change in an error message spelling that evidently came in with 3.2. Tristan Partin and Bo Andreson. Back-patch to all supported branches. Discussion: https://postgr.es/m/CAN55FZ1eDDYsYaL7mv+oSLUij2h_u6hvD4Qmv-7PK7jkji0uyQ@mail.gmail.com
* Fix exception safety bug in typcache.c.Thomas Munro2023-09-13
| | | | | | | | | | | | | | | | If an out-of-memory error was thrown at an unfortunate time, ensure_record_cache_typmod_slot_exists() could leak memory and leave behind a global state that produced an infinite loop on the next call. Fix by merging RecordCacheArray and RecordIdentifierArray into a single array. With only one allocation or re-allocation, there is no intermediate state. Back-patch to all supported releases. Reported-by: "James Pang (chaolpan)" <chaolpan@cisco.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://postgr.es/m/PH0PR11MB519113E738814BDDA702EDADD6EFA%40PH0PR11MB5191.namprd11.prod.outlook.com
* Cache by-reference missing values in a long lived contextAndrew Dunstan2023-08-22
| | | | | | | | | | | | | | | | Attribute missing values might be needed past the lifetime of the tuple descriptors from which they are extracted. To avoid possibly using pointers for by-reference values which might thus be left dangling, we cache a datumCopy'd version of the datum in the TopMemoryContext. Since we first search for the value this only needs to be done once per session for any such value. Original complaint from Tom Lane, idea for mitigation by Andrew Dunstan, tweaked by Tom Lane. Backpatch to version 11 where missing values were introduced. Discussion: https://postgr.es/m/1306569.1687978174@sss.pgh.pa.us
* Define OPENSSL_API_COMPATPeter Eisentraut2023-06-24
| | | | | | | | | | | | | | | | | | | This avoids deprecation warnings from newer OpenSSL versions (3.0.0 in particular). This has been originally applied as 4d3db13 for v14 and newer versions, but not on the older branches out of caution, and this commit closes the gap to remove all these deprecation warnings in all the branches still supported. OPENSSL_API_COMPAT's value is set based on the oldest version of OpenSSL supported on a branch: 1.0.1 for Postgres 13 and 0.9.8 for Postgres 11 and 12. Reviewed-by: Daniel Gustafsson Discussion: https://postgr.es/m/FEF81714-D479-4512-839B-C769D2605F8A@yesql.se Discussion: https://postgr.es/m/ZJJmOH+hIOSoesux@paquier.xyz Backpatch-through: 11
* Don't force SQL_ASCII/no-locale for installcheck in vcregress.plAndrew Dunstan2023-02-26
| | | | | | | | It's been this way for a very long time, but it appears to have been masking an issue that only manifests with different settings. Therefore, run the tests in the installation's default encoding/locale. Backpatch to all live branches.
* Fix handling of SCRAM-SHA-256's channel binding with RSA-PSS certificatesMichael Paquier2023-02-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OpenSSL 1.1.1 and newer versions have added support for RSA-PSS certificates, which requires the use of a specific routine in OpenSSL to determine which hash function to use when compiling it when using channel binding in SCRAM-SHA-256. X509_get_signature_nid(), that is the original routine the channel binding code has relied on, is not able to determine which hash algorithm to use for such certificates. However, X509_get_signature_info(), new to OpenSSL 1.1.1, is able to do it. This commit switches the channel binding logic to rely on X509_get_signature_info() over X509_get_signature_nid(), which would be the choice when building with 1.1.1 or newer. The error could have been triggered on the client or the server, hence libpq and the backend need to have their related code paths patched. Note that attempting to load an RSA-PSS certificate with OpenSSL 1.1.0 or older leads to a failure due to an unsupported algorithm. The discovery of relying on X509_get_signature_info() comes from Jacob, the tests have been written by Heikki (with few tweaks from me), while I have bundled the whole together while adding the bits needed for MSVC and meson. This issue exists since channel binding exists, so backpatch all the way down. Some tests are added in 15~, triggered if compiling with OpenSSL 1.1.1 or newer, where the certificate and key files can easily be generated for RSA-PSS. Reported-by: Gunnar "Nick" Bluth Author: Jacob Champion, Heikki Linnakangas Discussion: https://postgr.es/m/17760-b6c61e752ec07060@postgresql.org Backpatch-through: 11
* Fix binary mismatch for MSVC plperl vs gcc built perl libsAndrew Dunstan2022-11-27
| | | | | | | | | | | | | | | | When loading plperl built against Strawberry perl or the msys2 ucrt perl that have been built with gcc, a binary mismatch has been encountered which looks like this: loadable library and perl binaries are mismatched (got handshake key 0000000012800080, needed 0000000012900080) To cure this we bring the handshake keys into sync by adding NO_THREAD_SAFE_LOCALE to the defines used to build plperl. Discussion: https://postgr.es/m/20211005004334.tgjmro4kuachwiuc@alap3.anarazel.de Discussion: https://postgr.es/m/c2da86a0-2906-744c-923d-16da6047875e@dunslane.net Backpatch to all live branches.
* Improve setup of environment values for commands in MSVC's vcregress.plMichael Paquier2022-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current setup assumes that commands for lz4, zstd and gzip always exist by default if not enforced by a user's environment. However, vcpkg, as one example, installs libraries but no binaries, so this default setup to assume that a command should always be present would cause failures. This commit improves the detection of such external commands as follows: * If a ENV value is available, trust the environment/user and use it. * If a ENV value is not available, check its execution by looking in the current PATH, by launching a simple "$command --version" (that should be portable enough). ** On execution failure, ignore ENV{command}. ** On execution success, set ENV{command} = "$command". Note that this new rule applies to gzip, lz4 and zstd but not tar that we assume will always exist. Those commands are set up in the environment only when using bincheck and taptest. The CI includes all those commands and I have checked that their setup is correct there. I have also tested this change in a MSVC environment where we have none of those commands. While on it, remove the references to lz4 from the documentation and vcregress.pl in ~v13. --with-lz4 has been added in v14~ so there is no point to have this information in these older branches. Reported-by: Andrew Dunstan Reviewed-by: Andrew Dunstan Discussion: https://postgr.es/m/14402151-376b-a57a-6d0c-10ad12608e12@dunslane.net Backpatch-through: 10
* Allow clean.bat to be run from anywhereAndrew Dunstan2022-01-20
| | | | | | | | | | | This was omitted from c3879a7b4c which modified the other msvc .bat files. Per request from Juan José Santamaría Flecha Discussion: https://postgr.es/m/CAC+AXB0_fxYGbQoaYjCA8um7TTbOVP4L9aXnVmHwK8WzaT4gdA@mail.gmail.com Backpatch to all live branches.
* Avoid warning about uninitialized value in MSVC python3 testsAndrew Dunstan2022-01-10
| | | | | | Juan José Santamaría Flecha Backpatch to all live branches
* Allow MSVC .bat wrappers to be called from anywhereAndrew Dunstan2022-01-07
| | | | | | | | | | | | Instead of using a hardcoded or default path to the perl file the .bat file is a wrapper for, we use a path that means the file is found in the same directory as the .bat file. Patch by Anton Voloshin, slightly tweaked by me. Backpatch to all live branches Discussion: https://postgr.es/m/2b7a674b-5fb0-d264-75ef-ecc7a31e54f8@postgrespro.ru
* Adjust behavior of some env settings for the TAP tests of MSVCMichael Paquier2021-12-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | edc2332 has introduced in vcregress.pl some control on the environment variables LZ4, TAR and GZIP_PROGRAM to allow any TAP tests to be able use those commands. This makes the settings more consistent with src/Makefile.global.in, as the same default gets used for Make and MSVC builds. Each parameter can be changed in buildenv.pl, but as a default gets assigned after loading buldenv.pl, it is not possible to unset any of these, and using an empty value would not work with "||=" either. As some environments may not have a compatible command in their PATH (tar coming from MinGW is an issue, for one), this could break tests without an exit path to bypass any failing test. This commit changes things so as the default values for LZ4, TAR and GZIP_PROGRAM are assigned before loading buildenv.pl, not after. This way, we keep the same amount of compatibility as a GNU build with the same defaults, and it becomes possible to unset any of those values. While on it, this adds some documentation about those three variables in the section dedicated to the TAP tests for MSVC. Per discussion with Andrew Dunstan. Discussion: https://postgr.es/m/YbGYe483803il3X7@paquier.xyz Backpatch-through: 10
* Enable settings used in TAP tests for MSVC buildsAndrew Dunstan2021-12-07
| | | | | | | | | | | | | Certain settings from configuration or the Makefile infrastructure are used by the TAP tests, but were not being set up by vcregress.pl. This remedies those omissions. This should increase test coverage, especially on the buildfarm. Reviewed by Noah Misch Discussion: https://postgr.es/m/17093da5-e40d-8335-d53a-2bd803fc38b0@dunslane.net Backpatch to all live branches.
* Add support for Visual Studio 2022 in build scriptsMichael Paquier2021-11-24
| | | | | | | | | | | | | | Documentation and any code paths related to VS are updated to keep the whole consistent. Similarly to 2017 and 2019, the version of VS and the version of nmake that we use to determine which code paths to use for the build are still inconsistent in their own way. Backpatch down to 10, so as buildfarm members are able to use this new version of Visual Studio on all the stable branches supported. Author: Hans Buschmann Discussion: https://postgr.es/m/1633101364685.39218@nidsa.net Backpatch-through: 10
* Back-patch "Stop requiring an explicit return from perl subroutines"Noah Misch2021-10-23
| | | | | | Back-patch commit 0516f94d18c57cc5dce72ff8fb84a05d24a67063 to v12 and v11. Other back-patches will bring in code written to later standards. Per buildfarm member crake.
* Avoid race in RelationBuildDesc() affecting CREATE INDEX CONCURRENTLY.Noah Misch2021-10-23
| | | | | | | | | | | | | | | | | CIC and REINDEX CONCURRENTLY assume backends see their catalog changes no later than each backend's next transaction start. That failed to hold when a backend absorbed a relevant invalidation in the middle of running RelationBuildDesc() on the CIC index. Queries that use the resulting index can silently fail to find rows. Fix this for future index builds by making RelationBuildDesc() loop until it finishes without accepting a relevant invalidation. It may be necessary to reindex to recover from past occurrences; REINDEX CONCURRENTLY suffices. Back-patch to 9.6 (all supported versions). Noah Misch and Andrey Borodin, reviewed (in earlier versions) by Andres Freund. Discussion: https://postgr.es/m/20210730022548.GA1940096@gust.leadboat.com
* Fix build of MSVC with OpenSSL 3.0.0Michael Paquier2021-10-20
| | | | | | | | | | | | | The build scripts of Visual Studio would fail to detect properly a 3.0.0 build as the check on the second digit was failing. This is adjusted where needed, allowing the builds to complete. Note that the MSIs of OpenSSL mentioned in the documentation have not changed any library names for Win32 and Win64, making this change straight-forward. Reported-by: htalaco, via github Reviewed-by: Daniel Gustafsson Discussion: https://postgr.es/m/YW5XKYkq6k7OtrFq@paquier.xyz Backpatch-through: 9.6
* Fix WAL replay in presence of an incomplete recordAlvaro Herrera2021-09-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Physical replication always ships WAL segment files to replicas once they are complete. This is a problem if one WAL record is split across a segment boundary and the primary server crashes before writing down the segment with the next portion of the WAL record: WAL writing after crash recovery would happily resume at the point where the broken record started, overwriting that record ... but any standby or backup may have already received a copy of that segment, and they are not rewinding. This causes standbys to stop following the primary after the latter crashes: LOG: invalid contrecord length 7262 at A8/D9FFFBC8 because the standby is still trying to read the continuation record (contrecord) for the original long WAL record, but it is not there and it will never be. A workaround is to stop the replica, delete the WAL file, and restart it -- at which point a fresh copy is brought over from the primary. But that's pretty labor intensive, and I bet many users would just give up and re-clone the standby instead. A fix for this problem was already attempted in commit 515e3d84a0b5, but it only addressed the case for the scenario of WAL archiving, so streaming replication would still be a problem (as well as other things such as taking a filesystem-level backup while the server is down after having crashed), and it had performance scalability problems too; so it had to be reverted. This commit fixes the problem using an approach suggested by Andres Freund, whereby the initial portion(s) of the split-up WAL record are kept, and a special type of WAL record is written where the contrecord was lost, so that WAL replay in the replica knows to skip the broken parts. With this approach, we can continue to stream/archive segment files as soon as they are complete, and replay of the broken records will proceed across the crash point without a hitch. Because a new type of WAL record is added, users should be careful to upgrade standbys first, primaries later. Otherwise they risk the standby being unable to start if the primary happens to write such a record. A new TAP test that exercises this is added, but the portability of it is yet to be seen. This has been wrong since the introduction of physical replication, so backpatch all the way back. In stable branches, keep the new XLogReaderState members at the end of the struct, to avoid an ABI break. Author: Álvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Reviewed-by: Nathan Bossart <bossartn@amazon.com> Discussion: https://postgr.es/m/202108232252.dh7uxf6oxwcy@alvherre.pgsql
* Add fallback implementation for setenv()Michael Paquier2021-06-01
| | | | | | | | | | | | | | | | This fixes the code compilation on Windows with MSVC and Kerberos, as a missing implementation of setenv() causes a compilation failure of the GSSAPI code. This was only reproducible when building the code with Kerberos, something that buildfarm animal hamerkop has fixed recently. This issue only happens on 12 and 13, as this code has been introduced in b0b39f7. HEAD is already able to compile properly thanks to 7ca37fb0, and this commit is a minimal cherry-pick of it. Thanks to Tom Lane for the discussion. Discussion: https://postgr.es/m/YLDtm5WGjPxm6ua4@paquier.xyz Backpatch-through: 12
* fix syntax errorAndrew Dunstan2021-05-28
|
* Report configured port in MSVC built pg_configAndrew Dunstan2021-05-28
| | | | | | | This is a long standing omission, discovered when trying to write code that relied on it. Backpatch to all live branches.
* Fix MSVC scripts when building with GSSAPI/KerberosMichael Paquier2021-05-27
| | | | | | | | | | | | | | | | | | | | The deliverables of upstream Kerberos on Windows are installed with paths that do not match our MSVC scripts. First, the include folder was named "inc/" in our scripts, but the upstream MSIs use "include/". Second, the build would fail with 64-bit environments as the libraries are named differently. This commit adjusts the MSVC scripts to be compatible with the latest installations of upstream, and I have checked that the compilation was able to work with the 32-bit and 64-bit installations. Special thanks to Kondo Yuta for the help in investigating the situation in hamerkop, which had an incorrect configuration for the GSS compilation. Reported-by: Brian Ye Discussion: https://postgr.es/m/162128202219.27274.12616756784952017465@wrigleys.postgresql.org Backpatch-through: 9.6
* backpatch "jit: Add support for LLVM 12."Andres Freund2020-12-07
| | | | | | | | | As there haven't been problem on the buildfarm due to this change, backpatch 6c57f2ed16e now. Author: Andres Freund Discussion: https://postgr.es/m/20201016011244.pmyvr3ee2gbzplq4@alap3.anarazel.de Backpatch: 11-, where jit support was added
* Sync our copy of the timezone library with IANA release tzcode2020c.Tom Lane2020-10-16
| | | | | | | | | | | | | | | This changes zic's default output format from "-b fat" to "-b slim". We were already using "slim" in v13/HEAD, so those branches drop the explicit -b switch in the Makefiles. Instead, add an explicit "-b fat" in v12 and before, so that we don't change the output file format in those branches. (This is perhaps excessively conservative, but we decided not to do so in a12079109, and I'll stick with that.) Other non-cosmetic changes are to drop support for zic's long-obsolete "-y" switch, and to ensure that strftime() does not change errno unless it fails. As usual with tzcode changes, back-patch to all supported branches.
* Avoid need for valgrind suppressions for pg_atomic_init_u64 on some platforms.Andres Freund2020-06-08
| | | | | | | | | | | | | | | | | | | | Previously we used pg_atomic_write_64_impl inside pg_atomic_init_u64. That works correctly, but on platforms without 64bit single copy atomicity it could trigger spurious valgrind errors about uninitialized memory, because we use compare_and_swap for atomic writes on such platforms. I previously suppressed one instance of this problem (6c878edc1df), but as Tom reports that wasn't enough. As the atomic variable cannot yet be concurrently accessible during initialization, it seems better to have pg_atomic_init_64_impl set the value directly. Change pg_atomic_init_u32_impl for symmetry. Reported-By: Tom Lane Author: Andres Freund Discussion: https://postgr.es/m/1714601.1591503815@sss.pgh.pa.us Backpatch: 9.5-
* MSVC: Avoid warning when testing a TAP suite without PROVE_FLAGS.Noah Misch2020-06-07
| | | | | | | Commit 7be5d8df1f74b78620167d3abf32ee607e728919 surfaced the logic error, which had no functional implications, by adding "use warnings". The buildfarm always customizes PROVE_FLAGS, so the warning did not appear there. Back-patch to 9.5 (all supported versions).
* Refresh function name in CRC-associated Valgrind suppressions.Noah Misch2020-06-05
| | | | | | | | | Back-patch to 9.5, where commit 4f700bcd20c087f60346cb8aefd0e269be8e2157 first appeared. Reviewed by Tom Lane. Reported by Andrew Dunstan. Discussion: https://postgr.es/m/4dfabec2-a3ad-0546-2d62-f816c97edd0c@2ndQuadrant.com
* Fix MSVC installations with multiple "configure" files detectedMichael Paquier2020-05-21
| | | | | | | | | | | | | | | | When installing binaries and libraries using the MSVC installation routines, the operation gets done after moving to the root folder, whose location is detected by checking if "configure" exists two times in a row. So, calling the installation script from src/tools/msvc/ with an extra "configure" file four levels up the root path of the code tree causes the execution to go further up, leading to a failure in finding the builds. This commit fixes the issue by moving to the root folder of the code tree only once, when necessary. Author: Arnold Müller Reviewed-by: Daniel Gustafsson Discussion: https://postgr.es/m/16343-f638f67e7e52b86c@postgresql.org Backpatch-through: 9.5
* Handle spaces for Python install location in MSVC scriptsMichael Paquier2020-05-06
| | | | | | | | | | Attempting to use an installation path of Python that includes spaces caused the MSVC builds to fail. This fixes the issue by using the same quoting method as ad7595b for OpenSSL. Author: Victor Wagner Discussion: https://postgr.es/m/20200430150608.6dc6b8c4@antares.wagner.home Backpatch-through: 9.5
* Update Windows timezone name list to include currently-known zones.Tom Lane2020-04-24
| | | | | | Thanks to Juan José Santamaría Flecha. Discussion: https://postgr.es/m/5752.1587740484@sss.pgh.pa.us
* Improve placement of "display name" comment in win32_tzmap[] entries.Tom Lane2020-04-24
| | | | | | | | | | | | | | | | | | | | Sticking this comment at the end of the last line was a bad idea: it's not particularly readable, and it tempts pgindent to mess with line breaks within the comment, which in turn reveals that win32tzlist.pl's clean_displayname() does the wrong thing to clean up such line breaks. While that's not hard to fix, there's basically no excuse for this arrangement to begin with, especially since it makes the table layout needlessly vary across back branches with different pgindent rules. Let's just put the comment inside the braces, instead. This commit just moves and reformats the comments, and updates win32tzlist.pl to match; there's no actual data change. Per odd-looking results from Juan José Santamaría Flecha. Back-patch, since the point is to make win32_tzmap[] look the same in all supported branches again. Discussion: https://postgr.es/m/5752.1587740484@sss.pgh.pa.us
* Use a slightly more liberal regex to detect Visual Studio versionAndrew Dunstan2020-04-17
| | | | | | | | | | | Apparently in some language versions of Visual Studio nmake outputs some material after the version number and before the end of the line. This has been seen in Chinese versions. Therefore, we no longer demand that the version string comes at the end of a line. Per complaint from Cuiping Lin. Backpatch to all live branches.
* Turn off deprecated bison warnings under MSVCAndrew Dunstan2020-03-20
| | | | | | | These are disabled by the configure code, so this is just fixing an inconsistency in the MSVC code. Backpatch to all live branches.
* Handle spaces in OpenSSL install location for MSVCAndrew Dunstan2019-10-04
| | | | | | | | | First, make sure that the .exe name is quoted when trying to get the version number. Also, don't quote the lib name for using in the project files if it's already been quoted. This second change applies to all libraries, not just OpenSSL. This has clearly been broken forever, so backpatch to all live branches.
* Improve handling of NULLs in KNN-GiST and KNN-SP-GiSTAlexander Korotkov2019-09-19
| | | | | | | | | | | | | | | | | | | | | This commit improves subject in two ways: * It removes ugliness of 02f90879e7, which stores distance values and null flags in two separate arrays after GISTSearchItem struct. Instead we pack both distance value and null flag in IndexOrderByDistance struct. Alignment overhead should be negligible, because we typically deal with at most few "col op const" expressions in ORDER BY clause. * It fixes handling of "col op NULL" expression in KNN-SP-GiST. Now, these expression are not passed to support functions, which can't deal with them. Instead, NULL result is implicitly assumed. It future we may decide to teach support functions to deal with NULL arguments, but current solution is bugfix suitable for backpatch. Reported-by: Nikita Glukhov Discussion: https://postgr.es/m/826f57ee-afc7-8977-c44c-6111d18b02ec%40postgrespro.ru Author: Nikita Glukhov Reviewed-by: Alexander Korotkov Backpatch-through: 9.4
* Expand properly list of TAP tests used for prove in vcregress.plMichael Paquier2019-09-11
| | | | | | | | | | | | | | | Depending on the system used, t/*.pl may not be expanded into a list of tests which can be consumed by prove when attempting to run TAP tests on a given path. Fix that by using glob() directly in the script, to make sure that a complete list of tests is provided. This has not proved to be an issue with MSVC as the list was properly expanded, but it is on Linux with perl's system(). This is extracted from a larger patch. Author: Tom Lane Discussion: https://postgr.es/m/6628.1567958876@sss.pgh.pa.us Backpatch-through: 9.4
* Avoid using INFO elevel for what are fundamentally debug messages.Tom Lane2019-09-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 6f6b99d13 stuck an INFO message into the fast path for checking partition constraints, for no very good reason except that it made it easy for the regression tests to verify that that path was taken. Assorted later patches did likewise, increasing the unsuppressable-chatter level from ALTER TABLE even more. This isn't good for the user experience, so let's drop these messages down to DEBUG1 where they belong. So as not to have a loss of test coverage, create a TAP test that runs the relevant queries with client_min_messages = DEBUG1 and greps for the expected messages. This testing method is a bit brute-force --- in particular, it duplicates the execution of a fair amount of the core create_table and alter_table tests. We experimented with other solutions, but running any significant amount of standard testing with client_min_messages = DEBUG1 seems to have a lot of output-stability pitfalls, cf commits bbb96c370 and 5655565c0. Possibly at some point we'll look into whether we can reduce the amount of test duplication. Backpatch into v12, because some of these messages are new in v12 and we don't really want to ship it that way. Sergei Kornilov Discussion: https://postgr.es/m/81911511895540@web58j.yandex.ru Discussion: https://postgr.es/m/4859321552643736@myt5-02b80404fd9e.qloud-c.yandex.net
* Fix syntax error in commit 20e99cddd.Tom Lane2019-07-25
| | | | Per buildfarm.
* Honor MSVC WindowsSDKVersion if setAndrew Dunstan2019-07-25
| | | | | | | | | | | | Add a line to the project file setting the target SDK. Otherwise, in for example VS2017, if the default but optional 8.1 SDK is not installed the build will fail. Patch from Peifeng Qiu, slightly edited by me. Discussion: https://postgr.es/m/CABmtVJhw1boP_bd4=b3Qv5YnqEdL696NtHFi2ruiyQ6mFHkeQQ@mail.gmail.com Backpatch to all live branches.
* Add support for Visual Studio 2019 in build scriptsMichael Paquier2019-07-03
| | | | | | | | | | | | This fixes at the same time a set of inconsistencies in the documentation and the scripts related to the versions of Windows SDK supported. Author: Haribabu Kommi Reviewed-by: Andrew Dunstan, Juan José Santamaría Flecha, Michael Paquier Discussion: https://postgr.es/m/CAJrrPGcfqXhfPyMrny9apoDU7M1t59dzVAvoJ9AeAh5BJi+UzA@mail.gmail.com Backpatch-through: 9.4
* pgindent run prior to branching v12.Tom Lane2019-07-01
| | | | | pgperltidy and reformat-dat-files too, though the latter didn't find anything to change.
* Exclude new src/test/modules/unsafe_tests directory from MSVC build.Tom Lane2019-06-30
| | | | | There's nothing to build here, and that was confusing AddContrib(). Per buildfarm.
* Add support for OpenSSL 1.1.0 and newer versions in MSVC scriptsMichael Paquier2019-06-26
| | | | | | | | | | | | | | | | | | | | | Up to now, the MSVC build scripts are able to support only one fixed version of OpenSSL, and they lacked logic to detect the version of OpenSSL a given compilation of Postgres is linking to (currently 1.0.2, the latest LTS of upstream which will be EOL'd at the end of 2019). This commit adds more logic to detect the version of OpenSSL used by a build and makes use of it to add support for compilation with OpenSSL 1.1.0 which requires a new set of compilation flags to work properly. The supported OpenSSL installers have changed their library layer with various library renames with the upgrade to 1.1.0, making the logic a bit more complicated. The scripts are now able to adapt to the new world order. Reported-by: Sergey Pashkov Author: Juan José Santamaría Flecha, Michael Paquier Reviewed-by: Álvaro Herrera Discussion: https://postgr.es/m/15789-8fc75dea3c5a17c8@postgresql.org
* Remove last references to WAL segment size in MSVC scriptsMichael Paquier2019-06-19
| | | | | | | | fc49e24 has removed the last use of this compile-time variable as WAL segment size is something that can now be set at initdb time, still this commit has forgotten some references to it. Discussion: https://postgr.es/m/20190617073228.GE18917@paquier.xyz
* Fix more typos and inconsistencies in the treeMichael Paquier2019-06-17
| | | | | Author: Alexander Lakhin Discussion: https://postgr.es/m/0a5419ea-1452-a4e6-72ff-545b1a5a8076@gmail.com
generated by cgit v1.2.3 (git 2.25.1) at 2025-06-25 14:26:25 +0000