aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
...
* Avoid consuming an XID during vac_truncate_clog().Tom Lane2016-05-24
| | | | | | | | | | | | | | | | | | | vac_truncate_clog() uses its own transaction ID as the comparison point in a sanity check that no database's datfrozenxid has already wrapped around "into the future". That was probably fine when written, but in a lazy vacuum we won't have assigned an XID, so calling GetCurrentTransactionId() causes an XID to be assigned when otherwise one would not be. Most of the time that's not a big problem ... but if we are hard up against the wraparound limit, consuming XIDs during antiwraparound vacuums is a very bad thing. Instead, use ReadNewTransactionId(), which not only avoids this problem but is in itself a better comparison point to test whether wraparound has already occurred. Report and patch by Alexander Korotkov. Back-patch to all versions. Report: <CAPpHfdspOkmiQsxh-UZw2chM6dRMwXAJGEmmbmqYR=yvM7-s6A@mail.gmail.com>
* Fix range check for effective_io_concurrencyAlvaro Herrera2016-05-24
| | | | | | | | Commit 1aba62ec moved the range check of that option form guc.c into bufmgr.c, but introduced a bug by changing a >= 0.0 to > 0.0, which made the value 0 no longer accepted. Put it back. Reported by Jeff Janes, diagnosed by Tom Lane
* Fix typo in TAP test identification string.Tom Lane2016-05-23
| | | | Michael Paquier
* Fix BTREE_BUILD_STATS build.Tom Lane2016-05-23
| | | | | | | | | | Commit 65c5fcd353a859da9e61bfb2b92a99f12937de3b broke this by removing a header include directive that is conditionally required. Add that back to nbtree.c, with annotation to keep pgrminclude from re-breaking it. Peter Geoghegan Report: <CAM3SWZTNjHFYW_UG8bu0BnogqQ2HfsTgkzXLueuUhfTcYbu5HA@mail.gmail.com>
* Support IndexElem in raw_expression_tree_walker().Tom Lane2016-05-23
| | | | | | | | | Needed for cases in which INSERT ... ON CONFLICT appears inside a recursive CTE item. Per bug #14153 from Thomas Alton. Patch by Peter Geoghegan, slightly adjusted by me Report: <20160521232802.22598.13537@wrigleys.postgresql.org>
* Add support for more extensive testing of raw_expression_tree_walker().Tom Lane2016-05-23
| | | | | | | | | | | | | | | | | | | | | If RAW_EXPRESSION_COVERAGE_TEST is defined, do a no-op tree walk over every basic DML statement submitted to parse analysis. If we'd had this in place earlier, bug #14153 would have been caught by buildfarm testing. The difficulty is that raw_expression_tree_walker() is only used in limited cases involving CTEs (particularly recursive ones), so it's very easy for an oversight in it to not be noticed during testing of a seemingly-unrelated feature. The type of error we can expect to catch with this is complete omission of a node type from raw_expression_tree_walker(), and perhaps also recursion into a field that doesn't contain a node tree, though that would be an unlikely mistake. It won't catch failure to add new fields that need to be recursed into, unfortunately. I'll go enable this on one or two of my own buildfarm animals once bug #14153 is dealt with. Discussion: <27861.1464040417@sss.pgh.pa.us>
* Fix latent crash in do_text_output_multiline().Tom Lane2016-05-23
| | | | | | | | | | | | | | | | | | | | | do_text_output_multiline() would fail (typically with a null pointer dereference crash) if its input string did not end with a newline. Such cases do not arise in our current sources; but it certainly could happen in future, or in extension code's usage of the function, so we should fix it. To fix, replace "eol += len" with "eol = text + len". While at it, make two cosmetic improvements: mark the input string const, and rename the argument from "text" to "txt" to dodge pgindent strangeness (since "text" is a typedef name). Even though this problem is only latent at present, it seems like a good idea to back-patch the fix, since it's a very simple/safe patch and it's not out of the realm of possibility that we might in future back-patch something that expects sane behavior from do_text_output_multiline(). Per report from Hao Lee. Report: <CAGoxFiFPAGyPAJLcFxTB5cGhTW2yOVBDYeqDugYwV4dEd1L_Ag@mail.gmail.com>
* psql: Message style improvementsPeter Eisentraut2016-05-21
|
* Pin the built-in index access methods.Tom Lane2016-05-19
| | | | | | | | | | | | This was overlooked in commit 473b93287, which introduced DROP ACCESS METHOD. Although that command is restricted to superusers, we don't want even superusers dropping the built-in methods; "DROP ACCESS METHOD btree" in particular is unrecoverable from. Pin these objects in the same way that other initdb-created objects are pinned. I chose to bump catversion for this fix. That's not absolutely necessary perhaps, but it will ensure that no 9.6 production systems are missing the pin entries.
* Allocate all page images at once in generic wal interfaceTeodor Sigaev2016-05-17
| | | | | | That reduces number of allocation. Per gripe from Michael Paquier and Tom Lane suggestion.
* Correctly align page's images in generic wal APITeodor Sigaev2016-05-17
| | | | | | | Page image should be MAXALIGN'ed because existing code could directly align pointers in page instead of align offset from beginning of page. Found during play with indexes as extenstion, Alexander Korotkov and me
* Fix comment.Tom Lane2016-05-15
| | | | | Reference to getThreadLocalPQExpBuffer here seems inappropriate, since we aren't necessarily using that instantiation of getLocalPQExpBuffer.
* sql_features: Fix typosPeter Eisentraut2016-05-13
| | | | | | This makes the feature names match the SQL standard. From: Alexander Law <exclusion@gmail.com>
* Update release instructions for translation updatesPeter Eisentraut2016-05-13
| | | | | We don't tag the translations repository any more, because the commits into postgresql contain the git hashes, and that's authoritative.
* Fix bogus commentsAlvaro Herrera2016-05-12
| | | | | | Some comments mentioned XLogReplayBuffer, but there's no such function: that was an interim name for a function that got renamed to XLogReadBufferForRedo, before commit 2c03216d831160 was pushed.
* Fix obsolete commentAlvaro Herrera2016-05-12
|
* Fix infer_arbiter_indexes() to not barf on system columns.Tom Lane2016-05-11
| | | | | | | | | | | | | While it could be argued that rejecting system column mentions in the ON CONFLICT list is an unsupported feature, falling over altogether just because the table has a unique index on OID is indubitably a bug. As far as I can tell, fixing infer_arbiter_indexes() is sufficient to make ON CONFLICT (oid) actually work, though making a regression test for that case is problematic because of the impossibility of setting the OID counter to a known value. Minor cosmetic cleanups along with the bug fix.
* Fix assorted missing infrastructure for ON CONFLICT.Tom Lane2016-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | subquery_planner() failed to apply expression preprocessing to the arbiterElems and arbiterWhere fields of an OnConflictExpr. No doubt the theory was that this wasn't necessary because we don't actually try to execute those expressions; but that's wrong, because it results in failure to match to index expressions or index predicates that are changed at all by preprocessing. Per bug #14132 from Reynold Smith. Also add pullup_replace_vars processing for onConflictWhere. Perhaps it's impossible to have a subquery reference there, but I'm not exactly convinced; and even if true today it's a failure waiting to happen. Also add some comments to other places where one or another field of OnConflictExpr is intentionally ignored, with explanation as to why it's okay to do so. Also, catalog/dependency.c failed to record any dependency on the named constraint in ON CONFLICT ON CONSTRAINT, allowing such a constraint to be dropped while rules exist that depend on it, and allowing pg_dump to dump such a rule before the constraint it refers to. The normal execution path managed to error out reasonably for a dangling constraint reference, but ruleutils.c dumped core; so in addition to fixing the omission, add a protective check in ruleutils.c, since we can't retroactively add a dependency in existing databases. Back-patch to 9.5 where this code was introduced. Report: <20160510190350.2608.48667@wrigleys.postgresql.org>
* Fix autovacuum for shared relationsAlvaro Herrera2016-05-10
| | | | | | | | | | | | | | | | | | | | The table-skipping logic in autovacuum would fail to consider that multiple workers could be processing the same shared catalog in different databases. This normally wouldn't be a problem: firstly because autovacuum workers not for wraparound would simply ignore tables in which they cannot acquire lock, and secondly because most of the time these tables are small enough that even if multiple for-wraparound workers are stuck in the same catalog, they would be over pretty quickly. But in cases where the catalogs are severely bloated it could become a problem. Backpatch all the way back, because the problem has been there since the beginning. Reported by Ondřej Světlík Discussion: https://www.postgresql.org/message-id/572B63B1.3030603%40flexibee.eu https://www.postgresql.org/message-id/572A1072.5080308%40flexibee.eu
* Stamp 9.6beta1.REL9_6_BETA1Tom Lane2016-05-09
|
* Translation updatesPeter Eisentraut2016-05-09
| | | | | Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 17bf3e8564abf600274789fcc90e72532d5e7c05
* Wording quibbles regarding initdb usernameStephen Frost2016-05-08
| | | | | | | | | Use disallowed instead of reserved, cannot instead of can not, and double quotes instead of single quotes. Also add a test to cover the bug which started this discussion. Per discussion with Tom.
* Disallow superuser names starting with 'pg_' in initdbStephen Frost2016-05-08
| | | | | | | As with CREATE ROLE, disallow users from specifying initial superuser names which begin with 'pg_' in initdb. Per discussion with Tom.
* Fix poorly-worded log message.Tom Lane2016-05-08
| | | | Euler Taveira
* In new pg_dump TAP tests, remove trailing "$" from regexps using /m.Tom Lane2016-05-07
| | | | | | | | | | | | | | | | | | | It emerges that some Perl versions before 5.8.9 have a bug with regexps that use the /m flag and contain "$". This is the reason why jacana is still failing on HEAD, and I was able to duplicate the failure on prairiedog's host. There's no real need for "$" in these patterns, since they are already matching through the statement-terminating semicolons (or matching an explicit \n in some cases). So just remove it. Note: the reason jacana hasn't actually reported any failures in the last little while is that the way the pg_dump TAP tests are set up, any failure of this sort results in echoing the entire pg_dump dump output to stderr. Since there were about a hundred such failures, that resulted in a 30MB log file which choked the buildfarm upload script. There is room for improvement here :-(. Per off-list discussion with Andrew and Stephen.
* Clean up after pg_dump test runs.Tom Lane2016-05-06
| | | | | The tmp_check directory needs to be removed by "make clean", and also ignored by .gitignore.
* Fix pg_upgrade to not fail when new-cluster TOAST rules differ from old.Tom Lane2016-05-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch essentially reverts commit 4c6780fd17aa43ed, in favor of a much simpler solution for the case where the new cluster would choose to create a TOAST table but the old cluster doesn't have one: just don't create a TOAST table. The existing code failed in at least two different ways if the situation arose: (1) ALTER TABLE RESET didn't grab an exclusive lock, so that the lock sanity check in create_toast_table failed; (2) pg_upgrade did not provide a pg_type OID for the new toast table, so that the crosscheck in TypeCreate failed. While both these problems were introduced by later patches, they show that the hack being used to cause TOAST table creation is overwhelmingly fragile (and untested). I also note that before the TypeCreate crosscheck was added, the code would have resulted in assigning an indeterminate pg_type OID to the toast table, possibly causing a later OID conflict in that catalog; so that it didn't really work even when committed. If we simply don't create a TOAST table, there will only be a problem if the code tries to store a tuple that's wider than a page, and field compression isn't sufficient to get it under a page. Given that the TOAST creation threshold is intended to be about a quarter of a page, it's very hard to believe that cross-version differences in the do-we-need-a-toast- table heuristic could result in an observable problem. So let's just follow the old version's conclusion about whether a TOAST table is needed. (If we ever do change needs_toast_table() so much that this conclusion doesn't apply, we can devise a solution at that time, and hopefully do it in a less klugy way than 4c6780fd17aa43ed did.) Back-patch to 9.3, like the previous patch. Discussion: <8110.1462291671@sss.pgh.pa.us>
* Disable BLOB test in pg_dump TAP testsStephen Frost2016-05-06
| | | | | | | | | | Buildfarm member jacana appears to have an issue with running this test. It's not entirely clear to me why, but rather than try to fight with it, just disable it for now. None of the other tests try to write out from psql directly as this test does, so it seems likely that the rest of the tests will be fine (as they have been on numerous other systems).
* Mitigate "snapshot too old" performance regression on NUMAKevin Grittner2016-05-06
| | | | | | | | | | | | Limit maintenance of time to xid mapping to once per minute. At least in the tested case this brings performance within 5% of when the feature is off, compared to several times slower without this patch. While there, fix comments and whitespace. Ants Aasma, with cosmetic adjustments suggested by Andres Freund Reviewed by Kevin Grittner and Andres Freund
* Add test_pg_dump to @contrib_excludesStephen Frost2016-05-06
| | | | | | | | | | | | | The test_pg_dump extension doesn't have a C component, so we need to exclude it from the MSVC build system trying to figure out how to build it. Also add a "MODULES" line to the Makefile, as test_extensions has. Might not be necessary, but seems good to keep things consistent. Lastly, remove the 'installcheck' line from test_pg_dump, as that was causing redefinition errors, at least on my box. This also makes test_pg_dump consistent with how commit_ts is set up.
* Correct query in pg_dumpall:dumpRolesStephen Frost2016-05-06
| | | | | | | | We need to use a new branch due to the 9.5 addition of bypassrls when adding in the clause to exclude pg_* roles from being dumped by pg_dumpall. Pointed out by Noah, patch by me.
* Remove MODULES_big from test_pg_dumpStephen Frost2016-05-06
| | | | | | | | | | The Makefile for test_pg_dump shouldn't have a MODULES_big line because there's no actual compiled bit for that extension. Hopefully this will fix the Windows buildfarm members which were complaining. In passing, also add the 'prove_installcheck' bit to the pg_dump and test_pg_dump Makefiles, to get the buildfarm members to actually run those tests.
* Minimal fix for crash bug in quals_match_foreign_key.Robert Haas2016-05-06
| | | | | | | | Discussion is still underway as to whether to revert the entire patch that added this function, but that discussion may not conclude before beta1. So, in the meantime, let's do at least this much. David Rowley
* Limit maximum parallel degree to 1024.Robert Haas2016-05-06
| | | | | | | | | | | | | | This new limit affects both the max_parallel_degree GUC and the parallel_degree reloption. There may some day be a use case for using more than 1024 CPUs for a single query, but that's surely not the case right now. Not only do not very many people have that many CPUs, but the code hasn't been tested at that kind of scale and is very unlikely to perform well, or even work at all, without a lot more work. The issue addressed by commit 06bd458cb812623c3f1fdd55216c4c08b06a8447 is probably just one problem of many. The idea of a more reasonable limit here was suggested by Tom Lane; the value of 1024 was suggested by Amit Kapila.
* Improve pg_upgrade's report about failure to match up old and new tables.Tom Lane2016-05-06
| | | | | | | | | | | | | | | | | | | | Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all the relations it sees in the old and new databases. If it does, however, it just goes belly-up with a pretty unhelpful error message. That seemed fine as long as we expected the case never to occur in the wild, but Alvaro reported that it had been seen in a database whose pg_largeobject table had somehow acquired a TOAST table. That doesn't quite seem like a case that pg_upgrade actually needs to handle, but it would be good if the report were more diagnosable. Hence, extend the logic to print out as much information as we can about the mismatch(es) before we quit. In passing, improve the readability of get_rel_infos()'s data collection query, which had suffered seriously from lets-not-bother-to-update-comments syndrome, and generally was unnecessarily disrespectful to readers. It could be argued that this is a bug fix, but given that we have so few reports, I don't feel a need to back-patch; at least not before this has baked awhile in HEAD.
* Use mul_size when multiplying by the number of parallel workers.Robert Haas2016-05-06
| | | | | | | | | | That way, if the result overflows size_t, you'll get an error instead of undefined behavior, which seems like a plus. This also has the effect of casting the number of workers from int to Size, which is better because it's harder to overflow int than size_t. Dilip Kumar reported this issue and provided a patch upon which this patch is based, but his version did use mul_size.
* Remove various special checks around default rolesStephen Frost2016-05-06
| | | | | | | | | | | | | Default roles really should be like regular roles, for the most part. This removes a number of checks that were trying to make default roles extra special by not allowing them to be used as regular roles. We still prevent users from creating roles in the "pg_" namespace or from altering roles which exist in that namespace via ALTER ROLE, as we can't preserve such changes, but otherwise the roles are very much like regular roles. Based on discussion with Robert and Tom.
* Add TAP tests for pg_dumpStephen Frost2016-05-06
| | | | | | | | | | | | | | | | | | This TAP test suite will create a new cluster, populate it based on the 'create_sql' values in the '%tests' hash, run all of the runs defined in the '%pgdump_runs' hash, and then for each test in the '%tests' hash, compare each run's output the the regular expression defined for the test under the 'like' and 'unlike' functions, as appropriate. While this test suite covers a fair bit of ground (67% of pg_dump.c and quite a bit of the other files in src/bin/pg_dump), there is still quite a bit which remains to be added to provide better code coverage. Still, this is quite a bit better than we had, and has found a few bugs already (note that the CREATE TRANSFORM test is commented out, as it is currently failing). Idea for using the TAP system from Tom, though all of the code is mine.
* Only issue LOCK TABLE commands when necessaryStephen Frost2016-05-06
| | | | | | | | | | | | | | Reviewing the cases where we need to LOCK a given table during a dump, it was pointed out by Tom that we really don't need to LOCK a table if we are only looking to dump the ACL for it, or certain other components. After reviewing the queries run for all of the component pieces, a list of components were determined to not require LOCK'ing of the table. This implements a check to avoid LOCK'ing those tables. Initial complaint from Rushabh Lathia, discussed with Robert and Tom, the patch is mine.
* pg_dump performance and other fixesStephen Frost2016-05-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Do not try to dump objects which do not have ACLs when only ACLs are being requested. This results in a significant performance improvement as we can avoid querying for further information on these objects when we don't need to. When limiting the components to dump for an extension, consider what components have been requested. Initially, we incorrectly hard-coded the components of the extension objects to dump, which would mean that we wouldn't dump some components even with they were asked for and in other cases we would dump components which weren't requested. Correct defaultACLs to use 'dump_contains' instead of 'dump'. The defaultACL is considered a member of the namespace and should be dumped based on the same set of components that the other objects in the schema are, not based on what we're dumping for the namespace itself (which might not include ACLs, if the namespace has just the default or initial ACL). Use DUMP_COMPONENT_ACL for from-initdb objects, to allow users to change their ACLs, should they wish to. This just extends what we are doing for the pg_catalog namespace to objects which are not members of namespaces. Due to column ACLs being treated a bit differently from other ACLs (they are actually reset to NULL when all privileges are revoked), adjust the query which gathers column-level ACLs to consider all of the ACL-relevant columns.
* Correct pg_dump WHERE clause for functions/aggregatesStephen Frost2016-05-06
| | | | | | | | | The query to grab the function/aggregate information is now joining to pg_init_privs, so we can simplify (and correct) the WHERE clause used to determine if a given function's ACL has changed from the initial ACL on the function. Bug found by Noah, patch by me.
* Fix possible read past end of string in to_timestamp().Tom Lane2016-05-06
| | | | | | | | | | | | | | | | | | | | | | | to_timestamp() handles the TH/th format codes by advancing over two input characters, whatever those are. It failed to notice whether there were two characters available to be skipped, making it possible to advance the pointer past the end of the input string and keep on parsing. A similar risk existed in the handling of "Y,YYY" format: it would advance over three characters after the "," whether or not three characters were available. In principle this might be exploitable to disclose contents of server memory. But the security team concluded that it would be very hard to use that way, because the parsing loop would stop upon hitting any zero byte, and TH/th format codes can't be consecutive --- they have to follow some other format code, which would have to match whatever data is there. So it seems impractical to examine memory very much beyond the end of the input string via this bug; and the input string will always be in local memory not in disk buffers, making it unlikely that anything very interesting is close to it in a predictable way. So this doesn't quite rise to the level of needing a CVE. Thanks to Wolf Roediger for reporting this bug.
* Fix pgbench's parsing of double values to notice trailing garbage.Tom Lane2016-05-06
| | | | | Noted by Fabien Coelho, though this isn't exactly his proposed patch. (The technique used here is borrowed from the zic sources.)
* Improve handling of numeric-valued variables in pgbench.Tom Lane2016-05-06
| | | | | | | | | | | | | | | | | | | | | The previous coding always stored variable values as strings, doing conversion on-the-fly when a numeric value was needed or a number was to be assigned. This was a bit inefficient and risked loss of precision for floating-point values. The precision aspect had been hacked around by printing doubles in "%.18e" format, which is ugly and has machine-dependent results. Instead, arrange to preserve an assigned numeric value in the original binary numeric format, converting to string only when and if needed. When we do need to convert a double to string, convert in "%g" format with DBL_DIG precision, which is the standard way to do it and produces the least surprising results in most cases. The implementation supports storing both a string value and a numeric value for any one variable, with lazy conversion between them. I also arranged for lazy re-sorting of the variable array when new variables are added. That was mainly to allow a clean refactoring of putVariable() into two levels of subroutine, but it may allow us to save a few sorts. Discussion: <9188.1462475559@sss.pgh.pa.us>
* Fix hash index vs "snapshot too old" problemmsKevin Grittner2016-05-06
| | | | | | | | | | | | | | | | Hash indexes are not WAL-logged, and so do not maintain the LSN of index pages. Since the "snapshot too old" feature counts on detecting error conditions using the LSN of a table and all indexes on it, this makes it impossible to safely do early vacuuming on any table with a hash index, so add this to the tests for whether the xid used to vacuum a table can be adjusted based on old_snapshot_threshold. While at it, add a paragraph to the docs for old_snapshot_threshold which specifically mentions this and other aspects of the feature which may otherwise surprise users. Problem reported and patch reviewed by Amit Kapila
* Fix psql's \ev and \sv commands so that they handle view reloptions.Dean Rasheed2016-05-06
| | | | | | | | | | | Commit 8eb6407aaeb6cbd972839e356b436bb698f51cff added support for editing and showing view definitions, but neglected to account for view options such as security_barrier and WITH CHECK OPTION which are not returned by pg_get_viewdef() and so need special handling. Author: Dean Rasheed Reviewed-by: Peter Eisentraut Discussion: http://www.postgresql.org/message-id/CAEZATCWZjCgKRyM-agE0p8ax15j9uyQoF=qew7D2xB6cF76T8A@mail.gmail.com
* Move and rename fmtReloptionsArray().Dean Rasheed2016-05-06
| | | | | | | | | | | | Move fmtReloptionsArray() from pg_dump.c to string_utils.c so that it is available to other frontend code. In particular psql's \ev and \sv commands need it to handle view reloptions. Also rename the function to appendReloptionsArray(), which is a more accurate description of what it does. Author: Dean Rasheed Reviewed-by: Peter Eisentraut Discussion: http://www.postgresql.org/message-id/CAEZATCWZjCgKRyM-agE0p8ax15j9uyQoF=qew7D2xB6cF76T8A@mail.gmail.com
* Update time zone data files to tzdata release 2016d.Tom Lane2016-05-05
| | | | | | | DST law changes in Russia (Magadan, Tomsk regions) and Venezuela. Historical corrections for Russia. There are new zone names Europe/Kirov and Asia/Tomsk reflecting the fact that these regions now have different time zone histories from adjacent regions.
* Rename tsvector delete() to ts_delete(), and filter() to ts_filter().Tom Lane2016-05-05
| | | | | | | | | The similarity of the original names to SQL keywords seems like a bad idea. Rename them before we're stuck with 'em forever. In passing, minor code and docs cleanup. Discussion: <4875.1462210058@sss.pgh.pa.us>
* Rename pgbench min/max to least/greatest, and fix handling of double args.Tom Lane2016-05-05
| | | | | | | | | | | | These functions behave like the backend's least/greatest functions, not like min/max, so the originally-chosen names invite confusion. Per discussion, rename to least/greatest. I also took it upon myself to make them return double if any input is double. The previous behavior of silently coercing all inputs to int surely does not meet the principle of least astonishment. Copy-edit some of the other new functions' documentation, too.