summaryrefslogtreecommitdiff
path: root/src/port
Commit message (Collapse)AuthorAgeFilesLines
* Fix various typosDavid Rowley2023-04-181-1/+1
| | | | | | | | | | | | This fixes many spelling mistakes in comments, but a few references to invalid parameter names, function names and option names too in comments and also some in string constants Also, fix an #undef that was undefining the incorrect definition Author: Alexander Lakhin Reviewed-by: Justin Pryzby Discussion: https://postgr.es/m/d5f68d19-c0fc-91a9-118d-7c6a5a3f5fad@gmail.com
* Fix detection of unseekable files for fseek() and ftello() with MSVCMichael Paquier2023-04-124-19/+148
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Calling fseek() or ftello() on a handle to a non-seeking device such as a pipe or a communications device is not supported. Unfortunately, MSVC's flavor of these routines, _fseeki64() and _ftelli64(), do not return an error when given a pipe as handle. Some of the logic of pg_dump and restore relies on these routines to check if a handle is seekable, causing failures when passing the contents of pg_dump to pg_restore through a pipe, for example. This commit introduces wrappers for fseeko() and ftello() on MSVC so as any callers are able to properly detect the cases of non-seekable handles. This relies mainly on GetFileType(), sharing a bit of code with the MSVC port for fstat(). The code in charge of getting a file type is refactored into a new file called win32common.c, shared by win32stat.c and the new win32fseek.c. It includes the MSVC ports for fseeko() and ftello(). Like 765f5df, this is backpatched down to 14, where the fstat() implementation for MSVC is able to understand about files larger than 4GB in size. Using a TAP test for that is proving to be tricky as IPC::Run handles the pipes by itself, still I have been able to check the fix manually. Reported-by: Daniel Watzinger Author: Juan José Santamaría Flecha, Michael Paquier Discussion: https://postgr.es/m/CAC+AXB26a4EmxM2suXxPpJaGrqAdxracd7hskLg-zxtPB50h7A@mail.gmail.com Backpatch-through: 14
* Use nanosleep() to implement pg_usleep().Thomas Munro2023-03-151-15/+10
| | | | | | | | | | | | | | | | | | | | | The previous coding based on select() had commentary about historical portability concerns. Use POSIX nanosleep() instead. This has independently been suggested a couple of times before, but never managed to stick. Since recent and proposed work removes other uses of select(), and associated code and comments relating to its non-portable interaction with signals, it seems like a good time to tidy up this case, too. Also modernize the explanation of why WaitLatch() is a better way to wait. Reviewed-by: Nathan Bossart <nathandbossart@gmail.com> Suggested-by: Paul Guo <paulguo@gmail.com> Suggested-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/CAAKRu_b-q0hXCBUCAATh0Z4Zi6UkiC0k2DFgoD3nC-r3SkR3tg%40mail.gmail.com Discussion: https://postgr.es/m/CABQrizfxpBLZT5mZeE0js5oCh1tqEWvcGF3vMRCv5P-RwUY5dQ@mail.gmail.com Discussion: https://postgr.es/m/4902.1552349020@sss.pgh.pa.us
* Update obsolete comment about pg_usleep() accuracy.Thomas Munro2023-03-151-3/+4
| | | | | | | | | | | There are still some systems that use traditional tick-based sleep timing, but many including Linux, FreeBSD and macOS started using high resolution timer hardware more directly a decade or two ago. Update our comment about that. Also highlight that Windows is like the older Unixen in that respect. Author: Nathan Bossart <nathandbossart@gmail.com> Discussion: https://postgr.es/m/CA%2BhUKG%2BogAon8_V223Ldv6taPR2uKH3X_UJ_A7LJAf3-VRARPA%40mail.gmail.com
* Improve WIN32 port of fstat() to detect more file typesMichael Paquier2023-03-151-17/+49
| | | | | | | | | | | | | | | | | | | | | The current implementation of _pgfstat64() is ineffective in detecting a terminal handle or an anonymous named pipe. This commit improves our port of fstat() to detect more efficiently such cases by relying on GetFileType(), and returning more correct data when the type found is either a FILE_TYPE_PIPE (_S_IFIFO) or a FILE_TYPE_CHAR (_S_IFCHR). This is part of a more global fix to address failures when feeding the output generated by pg_dump to pg_restore through a pipe, for example, but not all of it. We are also going to need to do something about fseek() and ftello() which are not reliable on WIN32 for the same cases where fstat() was incorrect. Fixing fstat() is independent of the rest, though, which is why both fixes are handled separately, and this is the first part of it. Reported-by: Daniel Watzinger Author: Daniel Watzinger, Juan José Santamaría Flecha Discussion: https://postgr.es/m/b1448cd7-871e-20e3-8398-895e2d1d3bf9@gmail.com Backpatch-through: 14
* Remove gratuitous references to postmaster programPeter Eisentraut2023-01-261-1/+1
| | | | | | | | "postgres" has long been officially preferred over "postmaster" as the name of the program to invoke to run the server. Some example scripts and code comments still used the latter. Change those. Discussion: https://www.postgresql.org/message-id/flat/ece84b69-8f94-8b88-925f-64207cb3a2f0@enterprisedb.com
* Update copyright for 2023Bruce Momjian2023-01-0248-48/+48
| | | | Backpatch-through: 11
* Add copyright notices to meson filesAndrew Dunstan2022-12-201-0/+2
| | | | Discussion: https://postgr.es/m/222b43a5-2fb3-2c1b-9cd0-375d376c8246@dunslane.net
* meson: Basic cygwin supportAndres Freund2022-12-061-0/+4
| | | | | | | | | | | There likely are further issues, but as evidenced by the CI task proposed by Justin in the referenced thread, this suffices to build and run basic tests in cygwin (some fixes for the test infrastructure are needed, but that's independent of the meson aspect). Author: Justin Pryzby <pryzby@telsasoft.com> Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/20221021034040.GT16921@telsasoft.com
* autoconf: Unify CFLAGS_SSE42 and CFLAGS_ARMV8_CRC32CAndres Freund2022-12-011-9/+9
| | | | | | | | | | | | | | | | | | Until now we emitted the cflags to build the CRC objects into architecture specific variables. That doesn't make a whole lot of sense to me - we're never going to target x86 and arm at the same time, so they don't need to be separate variables. It might be better to instead continue to have CFLAGS_SSE42 / CFLAGS_ARMV8_CRC32C be computed by PGAC_ARMV8_CRC32C_INTRINSICS / PGAC_SSE42_CRC32_INTRINSICS and then set CFLAGS_CRC based on those. But it seems unlikely that we'd need other sets of CRC specific flags for those two architectures at the same time. This simplifies the upcoming meson PGXS compatibility. Reviewed-by: Peter Eisentraut <peter.eisentraut@enterprisedb.com> Discussion: https://postgr.es/m/20221005200710.luvw5evhwf6clig6@awork3.anarazel.de
* Provide sigaction() for Windows.Thomas Munro2022-11-091-5/+6
| | | | | | | | | | Commit 9abb2bfc left behind code to block signals inside signal handlers on Windows, because our signal porting layer didn't have sigaction(). Provide a minimal implementation that is capable of blocking signals, to get rid of platform differences. See also related commit c94ae9d8. Discussion: https://postgr.es/m/CA%2BhUKGKKKfcgx6jzok9AYenp2TNti_tfs8FMoJpL8%2B0Gsy%3D%3D_A%40mail.gmail.com
* Fix unlink() for STATUS_DELETE_PENDING on Windows.Thomas Munro2022-10-251-2/+36
| | | | | | | | | | | | | | | | | | | | Commit f357233c assumed that it was OK to return ENOENT directly if lstat() failed that way. If we got STATUS_DELETE_PENDING while trying to unlink a file that we had already unlinked successfully once before but someone else still had open (on a kernel version that has "pending" unlinks by default), then we would no longer reach the retry loop in pgunlink(). That loop claims to be only for handling sharing violations (a different phenomenon), but the errno is the same. Restore that behavior with an explicit check, to see if it fixes the occasional 'directory not empty' failures seen in the pg_upgrade tests on CI. Further improvements are possible with proposed upgrades to modern Windows APIs that would replace this convoluted code. Reported-by: Justin Pryzby <pryzby@telsasoft.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://postgr.es/m/20220920013122.GA31833%40telsasoft.com Discussion: https://postgr.es/m/CA%2BhUKG%2BajSQ_8eu2AogTncOnZ5me2D-Cn66iN_-wZnRjLN%2Bicg%40mail.gmail.com
* Fix stat() for recursive junction points on Windows.Thomas Munro2022-10-251-13/+13
| | | | | | | | | | | | | | | | Commit c5cb8f3b supposed that we'd only ever have to follow one junction point in stat(), because we don't construct longer chains of them ourselves. When examining a parent directory supplied by the user, we should really be able to cope with longer chains, just in case someone has their system set up that way. Choose an arbitrary cap of 8, to match the minimum acceptable value of SYMLOOP_MAX in POSIX. Previously I'd avoided reporting ELOOP thinking Windows didn't have it, but it turns out that it does, so we can use the proper error number. Reviewed-by: Roman Zharkov <r.zharkov@postgrespro.ru> Discussion: https://postgr.es/m/CA%2BhUKGJ7JDGWYFt9%3D-TyJiRRy5q9TtPfqeKkneWDr1XPU1%2Biqw%40mail.gmail.com Discussion: https://postgr.es/m/CA%2BhUKG%2BajSQ_8eu2AogTncOnZ5me2D-Cn66iN_-wZnRjLN%2Bicg%40mail.gmail.com
* Fix readlink() for non-PostgreSQL junction points on Windows.Thomas Munro2022-10-251-3/+14
| | | | | | | | | | | | | | | | | | | Since commit c5cb8f3b taught stat() to follow symlinks, and since initdb uses pg_mkdir_p(), and that examines parent directories, our humble readlink() implementation can now be exposed to junction points not of PostgreSQL origin. Those might be corrupted by our naive path mangling, which doesn't really understand NT paths in general. Simply decline to transform paths that don't look like a drive absolute path. That means that readlink() returns the NT path directly when checking a parent directory of PGDATA that happen to point to a drive using "rooted" format. That works for the purposes of our stat() emulation. Reported-by: Roman Zharkov <r.zharkov@postgrespro.ru> Reviewed-by: Roman Zharkov <r.zharkov@postgrespro.ru> Discussion: https://postgr.es/m/4590c37927d7b8ee84f9855d83229018%40postgrespro.ru Discussion: https://postgr.es/m/CA%2BhUKG%2BajSQ_8eu2AogTncOnZ5me2D-Cn66iN_-wZnRjLN%2Bicg%40mail.gmail.com
* Fix lstat() for broken junction points on Windows.Thomas Munro2022-10-252-5/+25
| | | | | | | | | | | | | When using junction points to emulate symlinks on Windows, one edge case was not handled correctly by commit c5cb8f3b: if a junction point is broken (pointing to a non-existent path), we'd report ENOENT. This doesn't break any known use case, but was noticed while developing a test suite for these functions and is fixed here for completeness. Also add translation ERROR_CANT_RESOLVE_FILENAME -> ENOENT, as that is one of the errors Windows can report for some kinds of broken paths. Discussion: https://postgr.es/m/CA%2BhUKG%2BajSQ_8eu2AogTncOnZ5me2D-Cn66iN_-wZnRjLN%2Bicg%40mail.gmail.com
* Fix readlink() return value on Windows.Thomas Munro2022-10-251-0/+3
| | | | | | Ancient bug noticed while working on a test suite for these functions. Discussion: https://postgr.es/m/CA%2BhUKG%2BajSQ_8eu2AogTncOnZ5me2D-Cn66iN_-wZnRjLN%2Bicg%40mail.gmail.com
* Fix symlink() errno on Windows.Thomas Munro2022-10-251-1/+10
| | | | | | Ancient bug noticed while working on a test suite for these functions. https://postgr.es/m/CA%2BhUKG%2BajSQ_8eu2AogTncOnZ5me2D-Cn66iN_-wZnRjLN%2Bicg%40mail.gmail.com
* Use libc's snprintf, not sprintf, for special cases in snprintf.c.Tom Lane2022-10-161-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | snprintf.c has always fallen back on libc's *printf implementation when printing pointers (%p) and floats. When this code originated, we were still supporting some platforms that lacked native snprintf, so we used sprintf for that. That's not actually unsafe in our usage, but nonetheless builds on macOS are starting to complain about sprintf being unconditionally deprecated; and I wouldn't be surprised if other platforms follow suit. There seems little reason to believe that any platform supporting C99 wouldn't have standards-compliant snprintf, so let's just use that instead to suppress such warnings. Back-patch to v12, which is where we started to require C99. It's also where we started to use our snprintf.c everywhere, so this wouldn't be enough to suppress the warning in older branches anyway --- that is, in older branches these aren't necessarily all our usages of libc's sprintf. It is enough in v12+ because any deprecation annotation attached to libc's sprintf won't apply to pg_sprintf. (Whether all our usages of pg_sprintf are adequately safe is not a matter I intend to address here, but perhaps it could do with some review.) Per report from Andres Freund and local testing. Discussion: https://postgr.es/m/20221015211955.q4cwbsfkyk3c4ty3@awork3.anarazel.de
* meson: Add support for building with precompiled headersAndres Freund2022-10-061-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This substantially speeds up building for windows, due to the vast amount of headers included via windows.h. A cross build from linux targetting mingw goes from 994.11user 136.43system 0:31.58elapsed 3579%CPU to 422.41user 89.05system 0:14.35elapsed 3562%CPU The wins on windows are similar-ish (but I don't have a system at hand just now for actual numbers). Targetting other operating systems the wins are far smaller (tested linux, macOS, FreeBSD). For now precompiled headers are disabled by default, it's not clear how well they work on all platforms. E.g. on FreeBSD gcc doesn't seem to have working support, but clang does. When doing a full build precompiled headers are only beneficial for targets with multiple .c files, as meson builds a separate precompiled header for each target (so that different compilation options take effect). This commit therefore only changes target with at least two .c files to use precompiled headers. Because this commit adds b_pch=false to the default_options new build directories will have precompiled headers disabled by default, however existing build directories will continue use the default value of b_pch, which is true. Note that using precompiled headers with ccache requires setting CCACHE_SLOPPINESS=pch_defines,time_macros to get hits. Reviewed-by: Peter Eisentraut <peter.eisentraut@enterprisedb.com> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Discussion: https://postgr.es/m/CA+hUKG+50eOUbN++ocDc0Qnp9Pvmou23DSXu=ZA6fepOcftKqA@mail.gmail.com Discussion: https://postgr.es/m/c5736f70-bb6d-8d25-e35c-e3d886e4e905@enterprisedb.com Discussion: https://postgr.es/m/20190826054000.GE7005%40paquier.xyz
* windows: Set UMDF_USING_NTSTATUS globally, include ntstatus.hAndres Freund2022-09-284-8/+0
| | | | | | | | | | | | | | | | We'd like to use precompiled headers on windows to reduce compile times. Right now we rely on defining UMDF_USING_NTSTATUS before including postgres.h in a few select places - which doesn't work with precompiled headers. Instead define it globally. When UMDF_USING_NTSTATUS is defined we need to explicitly include ntstatus.h, winternl.h to get a comparable set of symbols. Right now these includes would be required in a number of non-platform-specific .c files - to avoid that, include them in win32_port.h. Based on my measurements that doesn't increase compile times measurably. Reviewed-by: Thomas Munro <thomas.munro@gmail.com> Discussion: https://postgr.es/m/20220927011951.j3h4o7n6bhf7dwau@awork3.anarazel.de
* Map ERROR_INVALID_NAME to ENOENT in mapping table of win32error.cMichael Paquier2022-09-291-0/+3
| | | | | | | | | This error can be reached when sending an incorrect file name to open() on Windows, resulting in a confusing errno reported. This has been seen in the development of a different patch by the same author. Author: Bharath Rupireddy Discussion: https://postgr.es/m/CALj2ACWet-b8Juba0DiXwfGCyyOcohzwksahE5ebB9rcbLZKCQ@mail.gmail.com
* Restore pg_pread and friends.Thomas Munro2022-09-294-6/+8
| | | | | | | | | | | | | | | | | | | | Commits cf112c12 and a0dc8271 were a little too hasty in getting rid of the pg_ prefixes where we use pread(), pwrite() and vectored variants. We dropped support for ancient Unixes where we needed to use lseek() to implement replacements for those, but it turns out that Windows also changes the current position even when you pass in an offset to ReadFile() and WriteFile() if the file handle is synchronous, despite its documentation saying otherwise. Switching to asynchronous file handles would fix that, but have other complications. For now let's just put back the pg_ prefix and add some comments to highlight the non-standard side-effect, which we can now describe as Windows-only. Reported-by: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> Reviewed-by: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> Discussion: https://postgr.es/m/20220923202439.GA1156054%40nathanxps13
* meson: Add initial version of meson based build systemAndres Freund2022-09-211-0/+184
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Autoconf is showing its age, fewer and fewer contributors know how to wrangle it. Recursive make has a lot of hard to resolve dependency issues and slow incremental rebuilds. Our home-grown MSVC build system is hard to maintain for developers not using Windows and runs tests serially. While these and other issues could individually be addressed with incremental improvements, together they seem best addressed by moving to a more modern build system. After evaluating different build system choices, we chose to use meson, to a good degree based on the adoption by other open source projects. We decided that it's more realistic to commit a relatively early version of the new build system and mature it in tree. This commit adds an initial version of a meson based build system. It supports building postgres on at least AIX, FreeBSD, Linux, macOS, NetBSD, OpenBSD, Solaris and Windows (however only gcc is supported on aix, solaris). For Windows/MSVC postgres can now be built with ninja (faster, particularly for incremental builds) and msbuild (supporting the visual studio GUI, but building slower). Several aspects (e.g. Windows rc file generation, PGXS compatibility, LLVM bitcode generation, documentation adjustments) are done in subsequent commits requiring further review. Other aspects (e.g. not installing test-only extensions) are not yet addressed. When building on Windows with msbuild, builds are slower when using a visual studio version older than 2019, because those versions do not support MultiToolTask, required by meson for intra-target parallelism. The plan is to remove the MSVC specific build system in src/tools/msvc soon after reaching feature parity. However, we're not planning to remove the autoconf/make build system in the near future. Likely we're going to keep at least the parts required for PGXS to keep working around until all supported versions build with meson. Some initial help for postgres developers is at https://wiki.postgresql.org/wiki/Meson With contributions from Thomas Munro, John Naylor, Stone Tickle and others. Author: Andres Freund <andres@anarazel.de> Author: Nazir Bilal Yavuz <byavuz81@gmail.com> Author: Peter Eisentraut <peter@eisentraut.org> Reviewed-By: Peter Eisentraut <peter.eisentraut@enterprisedb.com> Discussion: https://postgr.es/m/20211012083721.hvixq4pnh2pixr3j@alap3.anarazel.de
* Include c.h instead of postgres.h in src/port/*p{read,write}*.cAndres Freund2022-09-174-4/+4
| | | | | | | | Frontend code shouldn't include postgres.h. Some files in src/port/ need to include postgres.h/postgres_fe.h, but these files don't. Discussion: https://postgr.es/m/20220915022626.5xx3ccgkzpkqw5mq@awork3.anarazel.de Backpatch: 12-, where 3fd2a7932ef introduced (some) of these files
* Clean up minor inconsistencies in pg_attribute_printf() usage.Tom Lane2022-09-161-3/+3
| | | | | | | | | | | | | | | | | | | | | For some reason we'd never decorated pg_v*printf() with pg_attribute_printf() annotations. There is a convention for how to label va_list-using printf functions (write zero for the second argument), and we use that liberally elsewhere in the code, but these core functions lacked it. It's not clear how much useful checking the compiler can do for calls of these, but we might as well add the annotations. Also, sync win32security.c's log_error() with our normal convention that pg_attribute_printf must be attached to a function's declaration not definition. Apparently this file is only compiled with compilers that aren't picky about that, but still it'd be better to be consistent. No back-patch since there's little reason to think we would catch anything. Discussion: https://postgr.es/m/3492412.1663283395@sss.pgh.pa.us
* Cleanup more code and comments related to Windows NT4 (XP days)Michael Paquier2022-08-301-1/+1
| | | | | | | | | | | All the code and comments cleaned up here is irrelevant since 495ed0e. Note that this removes an assumption that CreateRestrictedToken() may not exist, something that could have happened when running under Windows NT as the code stated. Rather than assuming that it may not exist, this causes pg_ctl to fail hard if the function cannot be loaded. Reported-by: Justin Pryzby Discussion: https://postgr.es/m/20220826112637.GD2342@telsasoft.com
* Remove configure probe for sockaddr_in6 and require AF_INET6.Thomas Munro2022-08-261-3/+2
| | | | | | | | | | | | | | | | | SUSv3 <netinet/in.h> defines struct sockaddr_in6, and all targeted Unix systems have it. Windows has it in <ws2ipdef.h>. Remove the configure probe, the macro and a small amount of dead code. Also remove a mention of IPv6-less builds from the documentation, since there aren't any. This is similar to commits f5580882 and 077bf2f2 for Unix sockets. Even though AF_INET6 is an "optional" component of SUSv3, there are no known modern operating system without it, and it seems even less likely to be omitted from future systems than AF_UNIX. Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/CA+hUKGKErNfhmvb_H0UprEmp4LPzGN06yR2_0tYikjzB-2ECMw@mail.gmail.com
* Remove replacement code for getaddrinfo.Thomas Munro2022-08-142-443/+0
| | | | | | | | | | SUSv3, all targeted Unixes and modern Windows have getaddrinfo() and related interfaces. Drop the replacement implementation, and adjust some headers slightly to make sure that the APIs are visible everywhere using standard POSIX headers and names. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/CA%2BhUKG%2BL_3brvh%3D8e0BW_VfX9h7MtwgN%3DnFHP5o7X2oZucY9dg%40mail.gmail.com
* Remove configure probe for sys/resource.h and refactor.Thomas Munro2022-08-141-8/+3
| | | | | | | | | | | | <sys/resource.h> is in SUSv2 and is on all targeted Unix systems. We have a replacement for getrusage() on Windows, so let's just move its declarations into src/include/port/win32/sys/resource.h so that we can use a standard-looking #include. Also remove an obsolete reference to CLK_TCK. Also rename src/port/getrusage.c to win32getrusage.c, following the convention for Windows-only fallback code. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/CA%2BhUKG%2BL_3brvh%3D8e0BW_VfX9h7MtwgN%3DnFHP5o7X2oZucY9dg%40mail.gmail.com
* Remove configure probe for sys/select.h.Thomas Munro2022-08-141-3/+1
| | | | | | | | | <sys/select.h> is in SUSv3 and every targeted Unix system has it. Provide an empty header in src/include/port/win32 so that we can include it unguarded even on Windows. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/CA%2BhUKG%2BL_3brvh%3D8e0BW_VfX9h7MtwgN%3DnFHP5o7X2oZucY9dg%40mail.gmail.com
* Remove configure probes for sys/un.h and struct sockaddr_un.Thomas Munro2022-08-141-3/+1
| | | | | | | | | | | | | | | | <sys/un.h> is in SUSv3 and every targeted Unix has it. Some Windows tool chains may still lack the approximately equivalent header <afunix.h>, so we already defined struct sockaddr_un ourselves on that OS for now. To harmonize things a bit, move our definition into a new header src/include/port/win32/sys/un.h. HAVE_UNIX_SOCKETS is now defined unconditionally. We migh remove that in a separate commit, pending discussion. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Peter Eisentraut <peter.eisentraut@enterprisedb.com> Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/CA%2BhUKG%2BL_3brvh%3D8e0BW_VfX9h7MtwgN%3DnFHP5o7X2oZucY9dg%40mail.gmail.com
* Simplify replacement code for strtof.Thomas Munro2022-08-071-38/+0
| | | | | | | | | | strtof() is in C99 and all targeted systems have it. We can remove the configure probe and some dead code, but we still need replacement code for a couple of systems that have known buggy implementations selected via platform template. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/152683.1659830125%40sss.pgh.pa.us
* Simplify gettimeofday for Windows.Thomas Munro2022-08-071-55/+12
| | | | | | | | | | | | | | | Previously we bothered to forward-declare struct timezone, following man pages on typical systems, but POSIX actually says the argument (which we ignore anyway) is void *. Drop a line. While here, add an assertion that nobody actually uses the tzp argument. Previously we did extra work to select between Windows APIs needed on older releases, but now we can just use the higher resolution function directly. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/CA%2BhUKGKwRpvGfcfq2qNVAQS2Wg1B9eA9QRhAmVSyJt1zsCN2sQ%40mail.gmail.com
* Simplify gettimeofday() fallback logic.Andres Freund2022-08-061-2/+2
| | | | | | | | | | | | | | | | | | There's no known supported system needing 1 argument gettimeofday() support. The test for it was added a long time ago (92c6bf9775b). Remove. Until now we tested whether a gettimeofday() fallback is needed when targetting windows. Which lead to the odd result that HAVE_GETTIMEOFDAY only being defined when targetting MinGW (which has gettimeofday() since at least 2007). As the fallback is specific to msvc, remove the configure code and rename src/port/gettimeofday.c to src/port/win32gettimeofday.c. While at it, also remove the definition of struct timezone, a forward declaration of the struct is sufficient. Reviewed-By: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-By: Thomas Munro <thomas.munro@gmail.com> Discussion: https://postgr.es/m/20220806000311.ywx65iuchvj4qn2k@awork3.anarazel.de
* Replace pgwin32_is_junction() with lstat().Thomas Munro2022-08-061-16/+0
| | | | | | | | | | | | | | | | | | | Now that lstat() reports junction points with S_IFLNK/S_ISLINK(), and unlink() can unlink them, there is no need for conditional code for Windows in a few places. That was expressed by testing for WIN32 or S_ISLNK, which we can now constant-fold. The coding around pgwin32_is_junction() was a bit suspect anyway, as we never checked for errors, and we also know that errors can be spuriously reported because of transient sharing violations on this OS. The lstat()-based code has handling for that. This also reverts 4fc6b6ee on master only. That was done because lstat() didn't previously work for symlinks (junction points), but now it does. Tested-by: Andrew Dunstan <andrew@dunslane.net> Discussion: https://postgr.es/m/CA%2BhUKGLfOOeyZpm5ByVcAt7x5Pn-%3DxGRNCvgiUPVVzjFLtnY0w%40mail.gmail.com
* Make unlink() work for junction points on Windows.Thomas Munro2022-08-061-1/+27
| | | | | | | | | To support harmonization of Windows and Unix code, teach our unlink() wrapper that junction points need to be unlinked with rmdir() on Windows. Tested-by: Andrew Dunstan <andrew@dunslane.net> Discussion: https://postgr.es/m/CA%2BhUKGLfOOeyZpm5ByVcAt7x5Pn-%3DxGRNCvgiUPVVzjFLtnY0w%40mail.gmail.com
* Provide lstat() for Windows.Thomas Munro2022-08-061-4/+106
| | | | | | | | | | | Junction points will be reported with S_ISLNK(x.st_mode), simulating POSIX lstat(). stat() will follow pseudo-symlinks, like in POSIX (but only one level before giving up, unlike in POSIX). This completes a TODO left by commit bed90759fcb. Tested-by: Andrew Dunstan <andrew@dunslane.net> (earlier version) Discussion: https://postgr.es/m/CA%2BhUKGLfOOeyZpm5ByVcAt7x5Pn-%3DxGRNCvgiUPVVzjFLtnY0w%40mail.gmail.com
* Remove configure probe for fdatasync.Thomas Munro2022-08-051-3/+3
| | | | | | | | | | | | | | | | | fdatasync() is in SUSv2, and all targeted Unix systems have it. We have a replacement function for Windows. We retain the probe for the function declaration, which allows us to supply the mysteriously missing declaration for macOS, and also for Windows. No need to keep a HAVE_FDATASYNC macro around. Also rename src/port/fdatasync.c to win32fdatasync.c since it's only for Windows. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/CA+hUKGJ3LHeP9w5Fgzdr4G8AnEtJ=z=p6hGDEm4qYGEUX5B6fQ@mail.gmail.com Discussion: https://postgr.es/m/CA%2BhUKGJZJVO%3DiX%2Beb-PXi2_XS9ZRqnn_4URh0NUQOwt6-_51xQ%40mail.gmail.com
* Simplify replacement code for preadv and pwritev.Thomas Munro2022-08-052-32/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | preadv() and pwritev() are not standardized by POSIX, but appeared in NetBSD in 1999 and were adopted by at least OpenBSD, FreeBSD, DragonFlyBSD, Linux, AIX, illumos and macOS. We don't use them much yet, but an active proposal uses them heavily. In 15, we had two replacement implementations for other OSes: one based on lseek() + -v function if available for true vector I/O, and the other based on a loop over p- function. The former would be an obstacle to hypothetical future multi-threaded code sharing file descriptors, while the latter would not, since commit cf112c12. Furthermore, the number of targeted systems that could benefit from the former's potential upside has dwindled to just one niche OS, since macOS added the functions and we de-supported HP-UX. That doesn't seem like a good trade-off. Therefore, drop the lseek()-based variant, and also the pg_ prefix now that the file position portability hazard is gone. At the time of writing, the only systems in our build farm that lack native preadv/pwritev and thus use fallback code are: * Solaris (but not illumos) * macOS before release 11.0 * Windows With this commit, the above systems will now use the *same* fallback code, the version that loops over pread()/pwrite(). Windows already used that (though a later proposal may include true vector I/O for Windows), so this decision really only affects Solaris, until it gets around to adding these system calls. Also remove some useless includes while here. Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/CA+hUKGJ3LHeP9w5Fgzdr4G8AnEtJ=z=p6hGDEm4qYGEUX5B6fQ@mail.gmail.com
* Remove dead pread and pwrite replacement code.Thomas Munro2022-08-054-40/+12
| | | | | | | | | | | | | | | | | | | | | | | pread() and pwrite() are in SUSv2, and all targeted Unix systems have them. Previously, we defined pg_pread and pg_pwrite to emulate these function with lseek() on old Unixen. The names with a pg_ prefix were a reminder of a portability hazard: they might change the current file position. That hazard is gone, so we can drop the prefixes. Since the remaining replacement code is Windows-only, move it into src/port/win32p{read,write}.c, and move the declarations into src/include/port/win32_port.h. No need for vestigial HAVE_PREAD, HAVE_PWRITE macros as they were only used for declarations in port.h which have now moved into win32_port.h. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Greg Stark <stark@mit.edu> Reviewed-by: Robert Haas <robertmhaas@gmail.com> Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/CA+hUKGJ3LHeP9w5Fgzdr4G8AnEtJ=z=p6hGDEm4qYGEUX5B6fQ@mail.gmail.com
* Remove dead setenv, unsetenv replacement code.Thomas Munro2022-08-052-113/+0
| | | | | | | | | | | | | | | | | | | | | setenv() and unsetenv() are in SUSv3 and targeted Unix systems have them. We still need special code for these on Windows, but that doesn't require a configure probe. This marks the first time we require a SUSv3 (POSIX.1-2001) facility (rather than SUSv2). The replacement code removed here was not needed on any targeted system or any known non-EOL'd Unix system, and was therefore dead and untested. No need for vestigial HAVE_SETENV and HAVE_UNSETENV macros, because we provide a replacement for Windows, and we didn't previously test the macros. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Greg Stark <stark@mit.edu> Reviewed-by: Robert Haas <robertmhaas@gmail.com> Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/CA+hUKGJ3LHeP9w5Fgzdr4G8AnEtJ=z=p6hGDEm4qYGEUX5B6fQ@mail.gmail.com
* Remove configure probe for link.Thomas Munro2022-08-051-6/+2
| | | | | | | | | | | | | | | link() is in SUSv2 and all targeted Unix systems have it. We have replacement code for Windows that doesn't require a configure probe. Since only Windows needs it, rename src/port/link.c to win32link.c like other similar things. There is no need for a vestigial HAVE_LINK macro, because we expect all Unix and, with our replacement function, Windows systems to have it, so we didn't have any tests around link() usage. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/CA+hUKGJ3LHeP9w5Fgzdr4G8AnEtJ=z=p6hGDEm4qYGEUX5B6fQ@mail.gmail.com
* Remove configure probe for dlopen, and refactor.Thomas Munro2022-08-051-7/+3
| | | | | | | | | | | | | | | | dlopen() is in SUSv2 and all targeted Unix systems have it. We still need replacement functions for Windows, but we don't need a configure probe for that. Since it's no longer needed by other operating systems, rename dlopen.c to win32dlopen.c and move the declarations into win32_port.h. Likewise, the macros RTLD_NOW and RTLD_GLOBAL now only need to be defined on Windows, since all targeted Unix systems have 'em. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/CA+hUKGJ3LHeP9w5Fgzdr4G8AnEtJ=z=p6hGDEm4qYGEUX5B6fQ@mail.gmail.com
* Remove dead getpwuid_r replacement code.Thomas Munro2022-07-241-54/+4
| | | | | | | | | | getpwuid_r is in SUSv2 and all targeted Unix systems have it. We don't use it for Windows. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Greg Stark <stark@mit.edu> Reviewed-by: Robert Haas <robertmhaas@gmail.com> Discussion: https://postgr.es/m/CA+hUKGJ3LHeP9w5Fgzdr4G8AnEtJ=z=p6hGDEm4qYGEUX5B6fQ@mail.gmail.com
* Remove dead getrusage replacement code.Thomas Munro2022-07-241-46/+3
| | | | | | | | | | | | | | | | getrusage() is in SUSv2 and all targeted Unix systems have it. Note that POSIX only covers ru_utime and ru_stime and we rely on many more fields without any kind of configure probe, but that predates this commit. The only supported system we need replacement code for now is Windows, and that can be done without a configure probe. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Greg Stark <stark@mit.edu> Reviewed-by: Robert Haas <robertmhaas@gmail.com> Discussion: https://postgr.es/m/CA+hUKGJ3LHeP9w5Fgzdr4G8AnEtJ=z=p6hGDEm4qYGEUX5B6fQ@mail.gmail.com
* Fix get_dirent_type() for Windows junction points.Thomas Munro2022-07-221-6/+10
| | | | | | | | | | | | | | | | | | | | Commit 87e6ed7c8 added code that intended to report Windows "junction points" as DT_LNK (the same way we report symlinks on Unix). Windows junction points are *also* directories according to the Windows attributes API, and we were reporting them as as DT_DIR. Change the order we check the attribute flags, to prioritize DT_LNK. If at some point we start using Windows' recently added real symlinks and need to distinguish them from junction points, we may need to rethink this, but for now this continues the tradition of wrapper functions that treat junction points as symlinks. Back-patch to 14, where get_dirent_type() landed. Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Discussion: https://postgr.es/m/CA%2BhUKGLzLK4PUPx0_AwXEWXOYAejU%3D7XpxnYE55Y%2Be7hB2N3FA%40mail.gmail.com Discussion: https://postgr.es/m/20220721111751.x7hod2xgrd76xr5c%40alvherre.pgsql
* Remove fls(), use pg_leftmost_one_pos32() instead.Thomas Munro2022-07-221-64/+0
| | | | | | | | | | | | | | Commit 4f658dc8 provided the traditional BSD fls() function in src/port/fls.c so it could be used in several places. Later we added a bunch of similar facilities in pg_bitutils.h, based on compiler builtins that map to hardware instructions. It's a bit confusing to have both 1-based and 0-based variants of this operation in use in different parts of the tree, and neither is blessed by a standard. Let's drop fls.c and the configure probe, and reuse the newer code. Reviewed-by: David Rowley <dgrowleyml@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/CA%2BhUKG%2B7dSX1XF8yFGmYk-%3D48dbjH2kmzZj16XvhbrWP-9BzRg%40mail.gmail.com
* Add wal_sync_method=fdatasync for Windows.Thomas Munro2022-07-202-1/+58
| | | | | | | | | | Windows 10 gained support for flushing NTFS files with fdatasync() semantics. The main advantage over open_datasync (in Windows API terms FILE_FLAG_WRITE_THROUGH) is that the latter does not flush SATA drive caches. The default setting is not changed, so users have to opt in to this. Discussion: https://postgr.es/m/CA%2BhUKGJZJVO%3DiX%2Beb-PXi2_XS9ZRqnn_4URh0NUQOwt6-_51xQ%40mail.gmail.com
* Replace many MemSet calls with struct initializationPeter Eisentraut2022-07-161-6/+2
| | | | | | | | | | | | | | This replaces all MemSet() calls with struct initialization where that is easily and obviously possible. (For example, some cases have to worry about padding bits, so I left those.) (The same could be done with appropriate memset() calls, but this patch is part of an effort to phase out MemSet(), so it doesn't touch memset() calls.) Reviewed-by: Ranier Vilela <ranier.vf@gmail.com> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Discussion: https://www.postgresql.org/message-id/9847b13c-b785-f4e2-75c3-12ec77a3b05c@enterprisedb.com
* Remove support for Visual Studio 2013Michael Paquier2022-07-142-37/+5
| | | | | | | | | | | | | | | | | | | | No members of the buildfarm are using this version of Visual Studio, resulting in all the code cleaned up here as being mostly dead, and VS2017 is the oldest version still supported. More versions could be cut, but the gain would be minimal, while removing only VS2013 has the advantage to remove from the core code all the dependencies on the value defined by _MSC_VER, where compatibility tweaks have accumulated across the years mostly around locales and strtof(), so that's a nice isolated cleanup. Note that this commit additionally allows a revert of 3154e16. The versions of Visual Studio now supported range from 2015 to 2022. Author: Michael Paquier Reviewed-by: Juan José Santamaría Flecha, Tom Lane, Thomas Munro, Justin Pryzby Discussion: https://postgr.es/m/YoH2IMtxcS3ncWn+@paquier.xyz
View Lorry Controller Status