- 03 9月, 2015 4 次提交
-
-
由 Fujii Masao 提交于
The setting values of some parameters including max_worker_processes must be equal to or higher than the values on the master. However, previously max_worker_processes was not listed as such parameter in the document. So this commit adds it to that list. Back-patch to 9.4 where max_worker_processes was added.
-
由 Noah Misch 提交于
Most suites already did so via start_test_server(), but the pg_rewind, pg_ctl and pg_controldata suites ran a postmaster or initdb with fsync enabled. This halves the pg_rewind suite's runtime on buildfarm member tern. It makes tern and that machine's other buildfarm members less vulnerable to noise failures from postmaster startup overrunning the 60s pg_ctl timeout. Back-patch to 9.5, where pg_rewind was introduced.
-
由 Robert Haas 提交于
listen_addresses needs to be handled differently now, and so does logging. Michael Paquier
-
由 Teodor Sigaev 提交于
Currently, in-memory posting list during GIN build process is limited 1GB because of using repalloc. The patch replaces call of repalloc to repalloc_huge. It increases limit of posting list from 180 millions (1GB / sizeof(ItemPointerData)) to 4 billions limited by maxcount/count fields in GinEntryAccumulator and subsequent calls. Check added. Also, fix accounting of allocatedMemory during build to prevent integer overflow with maintenance_work_mem > 4GB. Robert Abraham <robert.abraham86@googlemail.com> with additions by me
-
- 02 9月, 2015 5 次提交
-
-
由 Kevin Grittner 提交于
It appears that some attempt was made to do this using autocommit, but it wasn't effective (at least on Ubuntu 14.04).
-
由 Bruce Momjian 提交于
These are adjustments based on someone using the new standby upgrade steps. Report by Andy Colson Backpatch through 9.5
-
由 Robert Haas 提交于
Previously, if one background worker registered another background worker and set bgw_notify_pid while for the second background worker, it would not receive notifications from the postmaster unless, at the time the "parent" was registered, BGWORKER_BACKEND_DATABASE_CONNECTION was set. To fix, instead instead of including only those background workers that requested database connections in the postmater's BackendList, include them all. There doesn't seem to be any reason not do this, and indeed it removes a significant amount of duplicated code. The other option is to make PostmasterMarkPIDForWorkerNotify look at BackgroundWorkerList in addition to BackendList, but that adds more code duplication instead of getting rid of it. Patch by me. Review and testing by Ashutosh Bapat.
-
由 Alvaro Herrera 提交于
For clarity, so that the substeps are not numbered identically to the outer procedure's steps. Per report from Andy Colson in http://www.postgresql.org/message-id/55D789B5.7040308@squeakycode.net
- 01 9月, 2015 7 次提交
-
-
由 Tom Lane 提交于
Some googling turned up multiple sources saying that older versions of icc do not accept gcc-compatible asm blocks on IA64, though asm does work on x86[_64]. This is apparently fixed as of icc version 12.0 or so, but that doesn't help us much; if we have to carry the extra implementation anyway, we may as well just use it for icc rather than add a compiler version test. Hence, revert commit 2c713d6e (though I separated the icc code from the gcc code completely, producing what seems cleaner code). Document the state of affairs more explicitly, both in s_lock.h and postgres.c, and make some cosmetic adjustments around the IA64 code in s_lock.h.
-
由 Bruce Momjian 提交于
Patch by Josh Kupershmidt Backpatch through 9.5
-
由 Tom Lane 提交于
The atomics headers were written under the impression that icc doesn't handle gcc-style asm blocks, but this is demonstrably false on x86_[64], because s_lock.h has done it that way for more than a decade. (The jury is still out on whether this also works on ia64, so I'm leaving ia64-related code alone for the moment.) Treat gcc and icc the same in these headers. This is less code and it should improve the results for icc, because we hadn't gotten around to providing icc-specific implementations for most of the atomics.
-
由 Tom Lane 提交于
... just need to typedef sigset_t and provide sigemptyset/sigfillset, which are easy enough.
-
由 Tom Lane 提交于
Intel's icc is generally able to swallow asm blocks written for gcc. We have a few places that don't seem to know that, though. Experiment with removing the special case for icc in ia64_get_bsp(); if the buildfarm likes this, I'll try more cleanup. This is a good test case because it involves a "stop" notation that seems like it might not be very portable.
-
由 Tom Lane 提交于
Remove configure's checks for HAVE_POSIX_SIGNALS, HAVE_SIGPROCMASK, and HAVE_SIGSETJMP. These APIs are required by the Single Unix Spec v2 (POSIX 1997), which we generally consider to define our minimum required set of Unix APIs. Moreover, no buildfarm member has reported not having them since 2012 or before, which means that even if the code is still live somewhere, it's untested --- and we've made plenty of signal-handling changes of late. So just take these APIs as given and save the cycles for configure probes for them. However, we can't remove as much C code as I'd hoped, because the Windows port evidently still uses the non-POSIX code paths for signal masking. Since we're largely emulating these BSD-style APIs for Windows anyway, it might be a good thing to switch over to POSIX-like notation and thereby remove a few more #ifdefs. But I'm not in a position to code or test that. In the meantime, we can at least make things a bit more transparent by testing for WIN32 explicitly in these places.
-
由 Bruce Momjian 提交于
For some reason this message was not updated when the longtable option was added. Backpatch through 9.3
-
- 31 8月, 2015 3 次提交
-
-
由 Magnus Hagander 提交于
Josh Kupershmidt
-
由 Tom Lane 提交于
C89 requires <signal.h> to define sig_atomic_t, and there is no evidence in the buildfarm that any supported platforms don't comply. Remove the configure test to stop wasting build cycles on a purely historical issue. (Once upon a time, we cared about supporting C89-compliant compilers on machines with pre-C89 system headers, but that use-case has been dead for quite a few years.) I have some other fixes planned in this area, but let's start with this to see if the buildfarm produces any surprising results.
-
由 Joe Conway 提交于
The regression tests for sepgsql were broken by changes in the base distro as-shipped policies. Specifically, definition of unconfined_t in the system default policy was changed to bypass multi-category rules, which the regression test depended on. Fix that by defining a custom privileged domain (sepgsql_regtest_superuser_t) and using it instead of system's unconfined_t domain. The new sepgsql_regtest_superuser_t domain performs almost like the current unconfined_t, but restricted by multi-category policy as the traditional unconfined_t was. The custom policy module is a self defined domain, and so should not be affected by related future system policy changes. However, it still uses the unconfined_u:unconfined_r pair for selinux-user and role. Those definitions have not been changed for several years and seem less risky to rely on than the unconfined_t domain. Additionally, if we define custom user/role, they would need to be manually defined at the operating system level, adding more complexity to an already non-standard and complex regression test. Back-patch to 9.3. The regression tests will need more work before working correctly on 9.2. Starting with 9.2, sepgsql has had dependencies on libselinux versions that are only available on newer distros with the changed set of policies (e.g. RHEL 7.x). On 9.1 sepgsql works fine with the older distros with original policy set (e.g. RHEL 6.x), and on which the existing regression tests work fine. We might want eventually change 9.1 sepgsql regression tests to be more independent from the underlying OS policies, however more work will be needed to make that happen and it is not clear that it is worth the effort. Kohei KaiGai with review by Adam Brightwell and me, commentary by Stephen, Alvaro, Tom, Robert, and others.
-
- 30 8月, 2015 1 次提交
-
-
由 Tom Lane 提交于
On recent AIX it's necessary to configure gcc to use the native assembler (because the GNU assembler hasn't been updated to handle AIX 6+). This caused PG builds to fail with assembler syntax errors, because we'd try to compile s_lock.h's gcc asm fragment for PPC, and that assembly code relied on GNU-style local labels. We can't substitute normal labels because it would fail in any file containing more than one inlined use of tas(). Fortunately, that code is stable enough, and the PPC ISA is simple enough, that it doesn't seem like too much of a maintenance burden to just hand-code the branch offsets, removing the need for any labels. Note that the AIX assembler only accepts "$" for the location counter pseudo-symbol. The usual GNU convention is "."; but it appears that all versions of gas for PPC also accept "$", so in theory this patch will not break any other PPC platforms. This has been reported by a few people, but Steve Underwood gets the credit for being the first to pursue the problem far enough to understand why it was failing. Thanks also to Noah Misch for additional testing.
-
- 28 8月, 2015 4 次提交
-
-
由 Stephen Frost 提交于
During fireRIRrules(), get_row_security_policies can add to securityQuals and withCheckOptions. Make sure to lock any relations added at that point and before firing RIR rules on those expressions. Back-patch to 9.5 where RLS was added.
-
由 Andres Freund 提交于
Discussion: 20150827131352.GF2435@awork2.anarazel.de
-
由 Peter Eisentraut 提交于
The Perl chmod function already takes multiple file arguments, so we don't need a separate looping function.
-
由 Bruce Momjian 提交于
This makes the parameter names match the documented prototype names. Report by Erwin Brandstetter Backpatch through 9.0
-
- 27 8月, 2015 2 次提交
-
-
由 Tom Lane 提交于
Rather than consulting TransactionIdIsInProgress to see if an in-doubt transaction is still running, consult XidInMVCCSnapshot. That requires the same or fewer cycles as TransactionIdIsInProgress, and what's far more important, it does not access shared data structures (at least in the no-subxip-overflow case) so it incurs no contention. Furthermore, we would have had to check XidInMVCCSnapshot anyway before deciding that we were allowed to see the tuple. There should never be a case where XidInMVCCSnapshot says a transaction is done while TransactionIdIsInProgress says it's still running. The other way around is quite possible though. The result of that difference is that HeapTupleSatisfiesMVCC will no longer set hint bits on tuples whose source transactions recently finished but are still running according to our snapshot. The main cost of delaying the hint-bit setting is that repeated visits to a just-committed tuple, by transactions none of which have snapshots new enough to see the source transaction as done, will each execute TransactionIdIsCurrentTransactionId, which they need not have done before. However, that's normally just a small overhead, and no contention costs are involved; so it seems well worth the benefit of removing TransactionIdIsInProgress calls during the life of the source transaction. The core idea for this patch is due to Jeff Janes, who also did the legwork proving its performance benefits. His original proposal was to swap the order of TransactionIdIsInProgress and XidInMVCCSnapshot calls in some cases within HeapTupleSatisfiesMVCC. That was a bit messy though. The idea that we could dispense with calling TransactionIdIsInProgress altogether was mine, as is the final patch.
-
由 Bruce Momjian 提交于
Report by Peter Geoghegan Backpatch through 9.5
-
- 26 8月, 2015 5 次提交
-
-
由 Bruce Momjian 提交于
Report by Peter Geoghegan Backpatch through 9.5
-
由 Joe Conway 提交于
Until 9.4, pg_controldata output was all aligned. At some point during 9.5 development, a new item was added, namely "Current track_commit_timestamp setting:" which is two characters too long to be aligned with the rest of the output. Fix this by removing the noise word "Current" and adding the requisite number of padding spaces. Since the six preceding items are also similar in nature, remove "Current" and pad those as well in order to maintain overall consistency. Backpatch to 9.5 where new offending item was added.
-
由 Tom Lane 提交于
The default argument, if given, has to be of exactly the same datatype as the first argument; but this was not stated in so many words, and the error message you get about it might not lead your thought in the right direction. Per bug #13587 from Robert McGehee. A quick scan says that these are the only two built-in functions with two anyelement arguments and no other polymorphic arguments. There are plenty of cases of, eg, anyarray and anyelement, but those seem less likely to confuse. For instance this doesn't seem terribly hard to figure out: "function array_remove(integer[], numeric) does not exist". So I've contented myself with fixing these two cases.
-
由 Tom Lane 提交于
Per discussion, a little more verbosity seems called for.
-
由 Tom Lane 提交于
We had a report from Stefan Kaltenbrunner of a case in which postmaster log files overran available disk space because multiple backends spewed enormous context stats dumps upon hitting an out-of-memory condition. Given the lack of similar reports, this isn't a common problem, but it still seems worth doing something about. However, we don't want to just blindly truncate the output, because that might prevent diagnosis of OOM problems. What seems like a workable compromise is to limit the dump to 100 child contexts per parent, and summarize the space used within any additional child contexts. That should help because practical cases where the dump gets long will typically be huge numbers of siblings under the same parent context; while the additional debugging value from seeing details about individual siblings beyond 100 will not be large, we hope. Anyway it doesn't take much code or memory space to do this, so let's try it like this and see how things go. Since the summarization mechanism requires passing totals back up anyway, I took the opportunity to add a "grand total" line to the end of the printout.
-
- 25 8月, 2015 1 次提交
-
-
由 Tom Lane 提交于
The results of the KNN-search test cases were indeterminate, as they asked the system to sort pairs of points that are exactly equidistant from the query reference point. It's a bit surprising that we've seen no platform-specific failures from this in the buildfarm. Perhaps IEEE-float math is well enough standardized that no such failures will ever occur on supported platforms ... but since this entire regression test has yet to be shipped in any non-alpha release, that seems like an unduly optimistic assumption. Tweak the queries so that the correct output is uniquely defined. (The other queries in this test are also underdetermined; but it looks like they are regurgitating index rows in insertion order, so for the moment assume that that behavior is stable enough.) Per Greg Stark's experiments with VAX. Back-patch to 9.5 where this test script was introduced.
-
- 24 8月, 2015 3 次提交
-
-
由 Tom Lane 提交于
Try to avoid any possible confusion about what these messages mean.
-
由 Tom Lane 提交于
Previously, convert_one_string_to_scalar() would examine up to 20 bytes of the input string, producing a scalar conversion with theoretical precision far greater than is of any possible use considering the other limitations on the accuracy of the resulting selectivity estimate. (I think this choice might pre-date the caller-level logic that strips any common prefix of the strings; before that, there could have been value in scanning the strings far enough to use all the precision available in a double.) Aside from wasting cycles to little purpose, this choice meant that the "denom" variable could grow to as much as 256^21 = 3.74e50, which could overflow in some non-IEEE float arithmetics. While we don't really support any machines with non-IEEE arithmetic anymore, this still seems like quite an unnecessary platform dependency. Limit the scan to 12 bytes instead, thus limiting "denom" to 256^13 = 2.03e31, a value more likely to be computable everywhere. Per testing by Greg Stark, which showed overflow failures in our standard regression tests on VAX.
-
由 Tom Lane 提交于
Since the distances used in this algorithm are small integers (not more than the size of the U set, in fact), there is no good reason to use float arithmetic for them. Use short ints instead: they're smaller, faster, and require no special portability assumptions. Per testing by Greg Stark, which disclosed that the code got into an infinite loop on VAX for lack of IEEE-style float infinities. We don't really care all that much whether Postgres can run on a VAX anymore, but there seems sufficient reason to change this code anyway. In passing, make a few other small adjustments to make the code match usual Postgres coding style a bit better.
-
- 23 8月, 2015 3 次提交
-
-
由 Kevin Grittner 提交于
Merlin Moncure Backpatch to 9.5, where the misspelling was introduced
-
由 Peter Eisentraut 提交于
-
由 Peter Eisentraut 提交于
-
- 22 8月, 2015 2 次提交
-
-
由 Heikki Linnakangas 提交于
Fabien Coelho, reviewed by Julien Rouhaud
-
由 Tom Lane 提交于
For no obvious reason, spi_printtup() was coded to enlarge the tuple pointer table by just 256 slots at a time, rather than doubling the size at each reallocation, as is our usual habit. For very large SPI results, this makes for O(N^2) time spent in repalloc(), which of course soon comes to dominate the runtime. Use the standard doubling approach instead. This is a longstanding performance bug, so back-patch to all active branches. Neil Conway
-