aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
* Initialize all memory for logical replication relation cache.Andres Freund2017-04-23
| | | | | | | | | | | As reported by buildfarm animal skink / valgrind, some of the variables weren't always initialized. To avoid further mishaps use memset to ensure the entire entry is initialized. Author: Petr Jelinek Reported-By: Andres Freund Discussion: https://postgr.es/m/20170422183123.w2jgiuxtts7qrqaq@alap3.anarazel.de Backpatch: none, code new in master
* Remove select(2) backed latch implementation.Andres Freund2017-04-23
| | | | | | | | | | | | | poll(2) is required by Single Unix Spec v2, the usual baseline for postgres (leaving windows aside). There's not been any buildfarm animals without poll(2) for a long while, leaving the select(2) implementation to be largely untested. On windows, including mingw, poll() is not available, but we have a special case implementation for windows anyway. Author: Andres Freund Discussion: https://postgr.es/m/20170420003611.7r2sdvehesdyiz2i@alap3.anarazel.de
* Workaround for RecoverPreparedTransactions()Simon Riggs2017-04-23
| | | | | | Force overwriteOK = true while we investigate deeper fix Proposed by Tom Lane as temporary measure, accepted by me
* Fix LagTrackerRead() for timeline incrementsSimon Riggs2017-04-23
| | | | | | | | | Bug was masked by error in running 004_timeline_switch.pl that was fixed recently in 7d68f2281a. Detective work by Alvaro Herrera and Tom Lane Author: Thomas Munro
* Fix order of arguments to SubTransSetParent().Tom Lane2017-04-23
| | | | | | | | | | | | | | ProcessTwoPhaseBuffer (formerly StandbyRecoverPreparedTransactions) mixed up the parent and child XIDs when calling SubTransSetParent to record the transactions' relationship in pg_subtrans. Remarkably, analysis by Simon Riggs suggests that this doesn't lead to visible problems (at least, not in non-Assert builds). That might explain why we'd not noticed it before. Nonetheless, it's surely wrong. This code was born broken, so back-patch to all supported branches. Discussion: https://postgr.es/m/20110.1492905318@sss.pgh.pa.us
* Fix TAP infrastructure to support Mingw betterAndrew Dunstan2017-04-23
| | | | | | | archive_command and restore_command need to refer to Windows paths, not Msys virtual file system paths, as postgres is completely unaware of the latter, so prefix them with the Windows path to the virtual file system root. Clean psql and pg_recvlogical output of carriage returns.
* Make PostgresNode.pm check server status more carefully.Tom Lane2017-04-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | PostgresNode blithely ignored the exit status of pg_ctl, and in general made no effort to be sure that the server was running when it should be. This caused it to miss server crashes, which is a serious shortcoming in a test scaffold. Make it complain if pg_ctl fails, and modify the start and stop logic to complain if the server doesn't start, or doesn't stop, when expected. Also, have it turn off the "restart_after_crash" configuration parameter in created clusters, as bitter experience has shown that leaving that on can mask crashes too. We might at some point need variant functions that allow for, eg, server start failure to be expected. But no existing test case appears to want that, and it surely shouldn't be the default behavior. Note that this *will* break the buildfarm, as it will expose known bugs that the previous testing failed to. I'm committing it despite that, to verify that we get the expected failures in the buildfarm not just in manual testing. Back-patch into 9.6 where PostgresNode was introduced. (The 9.6 branch is not expected to show any failures.) Discussion: https://postgr.es/m/21432.1492886428@sss.pgh.pa.us
* Make PostgresNode::append_conf append a newline automatically.Tom Lane2017-04-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Although the documentation for append_conf said clearly that it didn't add a newline, many test authors seem to have forgotten that ... or maybe they just consulted the example at the top of the POD documentation, which clearly shows adding a config entry without bothering to add a trailing newline. The worst part of that is that it works, as long as you don't do it more than once, since the backend isn't picky about whether config files end with newlines. So there's not a strong forcing function reminding test authors not to do it like that. Upshot is that this is a terribly fragile way to go about things, and there's at least one existing test case that is demonstrably broken and not testing what it thinks it is. Let's just make append_conf append a newline, instead; that is clearly way safer than the old definition. I also cleaned up a few call sites that were unnecessarily ugly. (I left things alone in places where it's plausible that additional config lines would need to be added someday.) Back-patch the change in append_conf itself to 9.6 where it was added, as having a definitional inconsistency between branches would obviously be pretty hazardous for back-patching TAP tests. The other changes are just cosmetic and don't need to be back-patched. Discussion: https://postgr.es/m/19751.1492892376@sss.pgh.pa.us
* Require sufficiently modern version of Test::More for TAP testsAndrew Dunstan2017-04-22
| | | | | | Ancient versions of Test::More don't support the note() function used in some TAP tests, so we require the minimum version of the module that does.
* Partially revert commit 536d47bd9d5fce8d91929bee3128fa1d08dbcc57.Tom Lane2017-04-22
| | | | | | | | | | | | | Per buildfarm, the "#ifdef F_SETFD" removed in that commit actually is needed on Windows, because fcntl() isn't available at all on that platform, unless using Cygwin. We could perhaps spell it more like "#ifdef HAVE_FCNTL", or "#ifndef WIN32", but it's not clear that those choices are better. It does seem that we don't need the bogus manual definition of FD_CLOEXEC, though, so keep that change. Discussion: https://postgr.es/m/26254.1492805635@sss.pgh.pa.us
* Avoid depending on non-POSIX behavior of fcntl(2).Tom Lane2017-04-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The POSIX standard does not say that the success return value for fcntl(F_SETFD) and fcntl(F_SETFL) is zero; it says only that it's not -1. We had several calls that were making the stronger assumption. Adjust them to test specifically for -1 for strict spec compliance. The standard further leaves open the possibility that the O_NONBLOCK flag bit is not the only active one in F_SETFL's argument. Formally, therefore, one ought to get the current flags with F_GETFL and store them back with only the O_NONBLOCK bit changed when trying to change the nonblock state. In port/noblock.c, we were doing the full pushup in pg_set_block but not in pg_set_noblock, which is just weird. Make both of them do it properly, since they have little business making any assumptions about the socket they're handed. The other places where we're issuing F_SETFL are working with FDs we just got from pipe(2), so it's reasonable to assume the FDs' properties are all default, so I didn't bother adding F_GETFL steps there. Also, while pg_set_block deserves some points for trying to do things right, somebody had decided that it'd be even better to cast fcntl's third argument to "long". Which is completely loony, because POSIX clearly says the third argument for an F_SETFL call is "int". Given the lack of field complaints, these missteps apparently are not of significance on any common platforms. But they're still wrong, so back-patch to all supported branches. Discussion: https://postgr.es/m/30882.1492800880@sss.pgh.pa.us
* Change the on-disk format of SCRAM verifiers to conform to RFC 5803.Heikki Linnakangas2017-04-21
| | | | | | | | | | | | | | | | | | | It doesn't make any immediate difference to PostgreSQL, but might as well follow the standard, since one exists. (I looked at RFC 5803 earlier, but didn't fully understand it back then.) The new format uses Base64 instead of hex to encode StoredKey and ServerKey, which makes the verifiers slightly smaller. Using the same encoding for the salt and the keys also means that you only need one encoder/decoder instead of two. Although we have code in the backend to do both, we are talking about teaching libpq how to create SCRAM verifiers for PQencodePassword(), and libpq doesn't currently have any code for hex encoding. Bump catversion, because this renders any existing SCRAM verifiers in pg_authid invalid. Discussion: https://www.postgresql.org/message-id/351ba574-85ea-d9b8-9689-8c928dd0955d@iki.fi
* Remove long-obsolete catering for platforms without F_SETFD/FD_CLOEXEC.Tom Lane2017-04-21
| | | | | | | | | SUSv2 mandates that <fcntl.h> provide both F_SETFD and FD_CLOEXEC, so it seems pretty unlikely that any platforms remain without those. Remove the #ifdef-ery installed by commit 7627b91cd to see if the buildfarm agrees. Discussion: https://postgr.es/m/21444.1492798101@sss.pgh.pa.us
* Synchronize table list before creating slot in CREATE SUBSCRIPTIONPeter Eisentraut2017-04-21
| | | | | | | This way a failure to synchronize the table list will not leave an unused slot on the publisher. Author: Petr Jelinek <petr.jelinek@2ndquadrant.com>
* Add missing erand48.c to libpq/.gitignore.Tom Lane2017-04-20
| | | | | Oversight in commit 818fd4a67. While at it, sync order of file list in .gitignore with those in the Makefile.
* Sync pg_ctl documentation and usage message with reality.Tom Lane2017-04-20
| | | | | | | | Commit 05cd12ed5 ("pg_ctl: Change default to wait for all actions") was a tad sloppy about updating the documentation to match. The documentation was also sorely in need of a copy-editing pass, having been adjusted at different times by different people who took little care to maintain consistency of style.
* Modify message when partitioned table is added to publicationPeter Eisentraut2017-04-20
| | | | | | | | | Give a more specific error message than "xyz is not a table". Also document in CREATE PUBLICATION which kinds of relations are not supported. based on patch by Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
* Prevent log_replication_commands from causing SQL commands to be logged.Fujii Masao2017-04-21
| | | | | | | | | | | | | | | | | Commit 7c4f524 allowed walsender to execute normal SQL commands to support table sync feature in logical replication. Previously while log_statement caused such SQL commands to be logged, log_replication_commands caused them to be logged, too. That is, such SQL commands were logged twice unexpectedly when those settings were both enabled. This commit forces log_replication_commands to log only replication commands, to prevent normal SQL commands from being logged twice. Author: Masahiko Sawada Reviewed-by: Kyotaro Horiguchi Reported-by: Fujii Masao Discussion: http://postgr.es/m/CAHGQGwFDWh_Qr-q_GEMpD+qH=vYPMdVqw=ZOSY3kX_Pna9R9SA@mail.gmail.com
* Mark some columns in pg_subscription as NOT NULL.Fujii Masao2017-04-20
| | | | | | | | | | | | | | | In pg_subscription, subconninfo, subslotname, subsynccommit and subpublications are expected not to be NULL. Therefore this patch adds BKI_FORCE_NOT_NULL markings to them. This patch is basically unnecessary unless the code has a bug which wrongly sets either of those columns to NULL. But it's good to have this as a safeguard. Author: Masahiko Sawada Reviewed-by: Kyotaro Horiguchi Reported-by: Fujii Masao Discussion: http://postgr.es/m/CAHGQGwFDWh_Qr-q_GEMpD+qH=vYPMdVqw=ZOSY3kX_Pna9R9SA@mail.gmail.com
* Don't call the function that may raise an error while holding spinlock.Fujii Masao2017-04-20
| | | | | | | | | | | | | It's not safe to raise an error while holding spinlock. But previously logical replication worker for table sync called the function which reads the system catalog and may raise an error while it's holding spinlock. Which could lead to the trouble where spinlock will never be released and the server gets stuck infinitely. Author: Petr Jelinek Reviewed-by: Kyotaro Horiguchi and Fujii Masao Reported-by: Fujii Masao Discussion: http://postgr.es/m/CAHGQGwFDWh_Qr-q_GEMpD+qH=vYPMdVqw=ZOSY3kX_Pna9R9SA@mail.gmail.com
* Fix testing of parallel-safety of SubPlans.Tom Lane2017-04-18
| | | | | | | | | | | | | | | | | | | | | is_parallel_safe() supposed that the only relevant property of a SubPlan was the parallel safety of the referenced subplan tree. This is wrong: the testexpr or args subtrees might contain parallel-unsafe stuff, as demonstrated by the test case added here. However, just recursing into the subtrees fails in a different way: we'll typically find PARAM_EXEC Params representing the subplan's output columns in the testexpr. The previous coding supposed that any Param must be treated as parallel-restricted, so that a naive attempt at fixing this disabled parallel pushdown of SubPlans altogether. We must instead determine, for any visited Param, whether it is one that would be computed by a surrounding SubPlan node; if so, it's safe to push down along with the SubPlan node. We might later be able to extend this logic to cope with Params used for correlated subplans and other cases; but that's a task for v11 or beyond. Tom Lane and Amit Kapila Discussion: https://postgr.es/m/7064.1492022469@sss.pgh.pa.us
* Improve documentation and comment for quorum-based sync replication.Fujii Masao2017-04-19
| | | | | Author: Masahiko Sawada, heavily modified by me Discussion: http://postgr.es/m/CAHGQGwEKOw=SmPLxJzkBsH6wwDBgOnVz46QjHbtsiZ-d-2RGUg@mail.gmail.com
* Provide an error cursor for "can't call an SRF here" errors.Tom Lane2017-04-18
| | | | | | | | | | | | | | | | | | | | | | | | | Since it appears that v10 is going to move the goalposts by some amount in terms of where you can and can't invoke set-returning functions, arrange for the executor's "set-valued function called in context that cannot accept a set" errors to include a syntax position if possible, pointing to the specific SRF that can't be called where it's located. The main bit of infrastructure needed for this is to make the query source text accessible in the executor; but it turns out that commit 4c728f382 already did that. We just need a new function executor_errposition() modeled on parser_errposition(), and we're ready to rock. While experimenting with this, I noted that the error position wasn't properly reported if it occurred in a plpgsql FOR-over-query loop, which turned out to be because SPI_cursor_open_internal wasn't providing an error context callback during PortalStart. Fix that. There's a whole lot more that could be done with this infrastructure now that it's there, but this is not the right time in the development cycle for that sort of work. Hence, resist the temptation to plaster executor_errposition() calls everywhere ... for the moment. Discussion: https://postgr.es/m/5263.1492471571@sss.pgh.pa.us
* A collection of small fixes for logical replication.Fujii Masao2017-04-19
| | | | | | | | | | | | | | | | | | * Be sure to reset the launcher's pid (LogicalRepCtx->launcher_pid) to 0 even when the launcher emits an error. * Declare ApplyLauncherWakeup() as a static function because it's called only in launcher.c. * Previously IsBackendPId() was used to check whether the launcher's pid was valid. IsBackendPid() was necessary because there was the bug where the launcher's pid was not reset to 0. But now it's fixed, so IsBackendPid() is not necessary and this patch removes it. Author: Masahiko Sawada Reviewed-by: Kyotaro Horiguchi Reported-by: Fujii Masao Discussion: http://postgr.es/m/CAHGQGwFDWh_Qr-q_GEMpD+qH=vYPMdVqw=ZOSY3kX_Pna9R9SA@mail.gmail.com
* Use DatumGetInt32() to extract 32-bit integer value from a datum.Fujii Masao2017-04-19
| | | | | | | | | Previously DatumGetObjectId() was wrongly used for that. Author: Masahiko Sawada Reviewed-by: Kyotaro Horiguchi Reported-by: Fujii Masao Discussion: http://postgr.es/m/CAHGQGwFDWh_Qr-q_GEMpD+qH=vYPMdVqw=ZOSY3kX_Pna9R9SA@mail.gmail.com
* Also fix comment in sample postgresql.conf file, for "scram-sha-256".Heikki Linnakangas2017-04-18
| | | | Reported offlist by hubert depesz lubaczewski.
* Rename "scram" to "scram-sha-256" in pg_hba.conf and password_encryption.Heikki Linnakangas2017-04-18
| | | | | | | | | | | | | | | | | Per discussion, plain "scram" is confusing because we actually implement SCRAM-SHA-256 rather than the original SCRAM that uses SHA-1 as the hash algorithm. If we add support for SCRAM-SHA-512 or some other mechanism in the SCRAM family in the future, that would become even more confusing. Most of the internal files and functions still use just "scram" as a shorthand for SCRMA-SHA-256, but I did change PASSWORD_TYPE_SCRAM to PASSWORD_TYPE_SCRAM_SHA_256, as that could potentially be used by 3rd party extensions that hook into the password-check hook. Michael Paquier did this in an earlier version of the SCRAM patch set already, but I didn't include that in the version that was committed. Discussion: https://www.postgresql.org/message-id/fde71ff1-5858-90c8-99a9-1c2427e7bafb@iki.fi
* Fix minor typo in commentSimon Riggs2017-04-18
| | | | Reported-by: Amit Langote
* Exit correctly from PrepareRedoRemove() when not foundSimon Riggs2017-04-18
| | | | | | | | | Complex crash bug all started with this failure. Diagnosed and fixed by Nikhil Sontakke, reviewed by me. Reported-by: Jeff Janes Author: Nikhil Sontakke Discussion: https://postgr.es/m/CAMkU=1xBP8cqdS5eK8APHL=X6RHMMM2vG5g+QamduuTsyCwv9g@mail.gmail.com
* Don’t push nextid too far forwards in recoverySimon Riggs2017-04-18
| | | | | | | | | | | | | | Doing so allows various crash possibilities. Fix by avoiding having PrescanPreparedTransactions() increment ShmemVariableCache->nextXid when it has no 2PC files Bug found by Jeff Janes, diagnosis and patch by Pavan Deolasee, then patch re-designed for clarity and full accuracy by Michael Paquier. Reported-by: Jeff Janes Author: Pavan Deolasee, Michael Paquier Discussion: https://postgr.es/m/CAMkU=1zMLnH_i1-PVQ-biZzvNx7VcuatriquEnh7HNk6K8Ss3Q@mail.gmail.com
* Allow COMMENT ON COLUMN with partitioned tablesSimon Riggs2017-04-18
| | | | Amit Langote
* Set range table for CopyFrom() in tablesyncPeter Eisentraut2017-04-17
| | | | | | | | | | | | | | CopyFrom() needs a range table for formatting certain errors for constraint violations. This changes the mechanism of how the range table is passed to the CopyFrom() executor state. We used to generate the range table and one entry for the relation manually inside DoCopy(). Now we use addRangeTableEntryForRelation() to setup the range table and relation entry for the ParseState, which is then passed down by BeginCopyFrom(). Author: Petr Jelinek <petr.jelinek@2ndquadrant.com> Reported-by: Euler Taveira <euler@timbira.com.br>
* Rename columns in new pg_statistic_ext catalogAlvaro Herrera2017-04-17
| | | | | | | | | The new catalog reused a column prefix "sta" from pg_statistic, but this is undesirable, so change the catalog to use prefix "stx" instead. Also, rename the column that lists enabled statistic kinds as "stxkind" rather than "enabled". Discussion: https://postgr.es/m/CAKJS1f_2t5jhSN7huYRFH3w3rrHfG2QU7hiUHsu-Vdjd1rYT3w@mail.gmail.com
* Tighten up relation kind checks for extended statisticsAlvaro Herrera2017-04-17
| | | | | | | | | | | | We were accepting creation of extended statistics only for regular tables, but they can usefully be created for foreign tables, partitioned tables, and materialized views, too. Allow those cases. While at it, make sure all the rejected cases throw a consistent error message, and add regression tests for the whole thing. Author: David Rowley, Álvaro Herrera Discussion: https://postgr.es/m/CAKJS1f-BmGo410bh5RSPZUvOO0LhmHL2NYmdrC_Jm8pk_FfyCA@mail.gmail.com
* Always build a custom plan node's targetlist from the path's pathtarget.Tom Lane2017-04-17
| | | | | | | | | | | | | | | | | | | | | | | We were applying the use_physical_tlist optimization to all relation scan plans, even those implemented by custom scan providers. However, that's a bad idea for a couple of reasons. The custom provider might be unable to provide columns that it hadn't expected to be asked for (for example, the custom scan might depend on an index-only scan). Even more to the point, there's no good reason to suppose that this "optimization" is a win for a custom scan; whatever the custom provider is doing is likely not based on simply returning physical heap tuples. (As a counterexample, if the custom scan is an interface to a column store, demanding all columns would be a huge loss.) If it is a win, the custom provider could make that decision for itself and insert a suitable pathtarget into the path, anyway. Per discussion with Dmitry Ivanov. Back-patch to 9.5 where custom scan support was introduced. The argument that the custom provider can adjust the behavior by changing the pathtarget only applies to 9.6+, but on balance it seems more likely that use_physical_tlist will hurt custom scans than help them. Discussion: https://postgr.es/m/e29ddd30-8ef9-4da5-a50b-2bb7b8c7198d@postgrespro.ru
* Fix typos in comment and log message.Fujii Masao2017-04-18
|
* Fix new warnings from GCC 7Peter Eisentraut2017-04-17
| | | | | This addresses the new warning types -Wformat-truncation -Wformat-overflow that are part of -Wall, via -Wformat, in GCC 7.
* Fix perlcritic warningsPeter Eisentraut2017-04-17
|
* Fix extended statistics with partial analyzesAlvaro Herrera2017-04-17
| | | | | | | | | | | | Either because of a previous ALTER TABLE .. SET STATISTICS 0 or because of being invoked with a partial column list, ANALYZE could fail to acquire sufficient data to build extended statistics. Previously, this would draw an ERROR and fail to collect any statistics at all (extended and regular). Change things so that we raise a WARNING instead, and remove a hint that was wrong in half the cases. Reported by: David Rowley Discussion: https://postgr.es/m/CAKJS1f9Kk0NF6Fg7TA=JUXsjpS9kX6NVu27pb5QDCpOYAvb-Og@mail.gmail.com
* pg_dump: Emit ONLY before table added to publicationPeter Eisentraut2017-04-17
| | | | | | | This is necessary to be able to reproduce publication membership correctly if tables are involved in inheritance. Author: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
* Document that ONLY can be specified in publication commandsPeter Eisentraut2017-04-17
| | | | Author: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
* Ensure BackgroundWorker struct contents are well-defined.Tom Lane2017-04-16
| | | | | | | | Coverity complained because bgw.bgw_extra wasn't being filled in by ApplyLauncherRegister(). The most future-proof fix is to memset the whole BackgroundWorker struct to zeroes. While at it, let's apply the same coding rule to other places that set up BackgroundWorker structs; four out of five had the same or related issues.
* Fix typo in commentPeter Eisentraut2017-04-16
| | | | Author: Masahiko Sawada <sawada.mshk@gmail.com>
* Sync addRangeTableEntryForENR() with its peer functions.Tom Lane2017-04-16
| | | | | | | | | | | | | | addRangeTableEntryForENR had a check for pstate != NULL, which Coverity pointed out was rather useless since it'd already dereferenced pstate before that. More to the point, we'd established policy in commit bc93ac12c that we'd require non-NULL pstate for all addRangeTableEntryFor* functions; this test was evidently copied-and-pasted from some older version of one of those functions. Make it look more like the others. In passing, make an elog message look more like the rest of the code, too. Michael Paquier
* Make sure to run one initdb TAP test with no TZ setAndrew Dunstan2017-04-15
| | | | | | | That way we make sure that initdb's time zone setting code is exercised. This doesn't add an extra test, it just alters an existing test. Discussion: <https://postgr.es/m/5807.1492229253@sss.pgh.pa.us>
* Provide a way to control SysV shmem attach address in EXEC_BACKEND builds.Tom Lane2017-04-15
| | | | | | | | | | | | | | | | | | | | | | | | | In standard non-Windows builds, there's no particular reason to care what address the kernel chooses to map the shared memory segment at. However, when building with EXEC_BACKEND, there's a risk that the chosen address won't be available in all child processes. Linux with ASLR enabled (which it is by default) seems particularly at risk because it puts shmem segments into the same area where it maps shared libraries. We can work around that by specifying a mapping address that's outside the range where shared libraries could get mapped. On x86_64 Linux, 0x7e0000000000 seems to work well. This is only meant for testing/debugging purposes, so it doesn't seem necessary to go as far as providing a GUC (or any user-visible documentation, though we might change that later). Instead, it's just controlled by setting an environment variable PG_SHMEM_ADDR to the desired attach address. Back-patch to all supported branches, since the point here is to remove intermittent buildfarm failures on EXEC_BACKEND animals. Owners of affected animals will need to add a suitable setting of PG_SHMEM_ADDR to their build_env configuration. Discussion: https://postgr.es/m/7036.1492231361@sss.pgh.pa.us
* Fix erroneous cross-reference in comment.Tom Lane2017-04-15
| | | | | | | | Seems to have been introduced in commit c219d9b0a. I think there indeed was a "tupbasics.h" in some early drafts of that refactoring, but it didn't survive into the committed version. Amit Kapila
* More cleanup of manipulations of hash indexes' hasho_flag field.Tom Lane2017-04-15
| | | | | | | Not much point in defining test macros for the flag bits if we don't use 'em. Amit Kapila
* Downcase "Wincrypt.h"Andrew Dunstan2017-04-15
| | | | | | This is consistent with how we refer to other Windows include files, and prevents a failure when cross-compiling on a system with case sensitive file names.
* Avoid passing function pointers across process boundaries.Tom Lane2017-04-14
| | | | | | | | | | | | | | | | We'd already recognized that we can't pass function pointers across process boundaries for functions in loadable modules, since a shared library could get loaded at different addresses in different processes. But actually the practice doesn't work for functions in the core backend either, if we're using EXEC_BACKEND. This is the cause of recent failures on buildfarm member culicidae. Switch to passing a string function name in all cases. Something like this needs to be back-patched into 9.6, but let's see if the buildfarm likes it first. Petr Jelinek, with a bunch of basically-cosmetic adjustments by me Discussion: https://postgr.es/m/548f9c1d-eafa-e3fa-9da8-f0cc2f654e60@2ndquadrant.com
generated by cgit v1.2.3 (git 2.25.1) at 2025-07-24 11:18:00 +0000