aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* Translation updatesPeter Eisentraut2016-06-20
| | | | | Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 0c374f8d25ed31833a10d24252bc928d41438838
* Add missing documentation of pg_roles.rolbypassrlsMagnus Hagander2016-06-20
| | | | Noted by Lukas Fittl
* Docs: improve description of psql's %R prompt escape sequence.Tom Lane2016-06-19
| | | | | | | | | | | Dilian Palauzov pointed out in bug #14201 that the docs failed to mention the possibility of %R producing '(' due to an unmatched parenthesis. He proposed just adding that in the same style as the other options were listed; but it seemed to me that the sentence was already nearly unintelligible, so I rewrote it a bit more extensively. Report: <20160619121113.5789.68274@wrigleys.postgresql.org>
* Improve error message annotation for GRANT/REVOKE on untrusted PLs.Tom Lane2016-06-18
| | | | | | | | | | | | | | | | The annotation for "ERROR: language "foo" is not trusted" used to say "HINT: Only superusers can use untrusted languages", which was fairly poorly thought out. For one thing, it's not a hint about what to do, but a statement of fact, which makes it errdetail. But also, this fails to clarify things much, because there's a missing step in the chain of reasoning. I think it's more useful to say "GRANT and REVOKE are not allowed on untrusted languages, because only superusers can use untrusted languages". It's been like this for a long time, but given the lack of previous complaints, I don't think this is worth back-patching. Discussion: <1417.1466289901@sss.pgh.pa.us>
* Update 9.6 release notes through today.Tom Lane2016-06-18
|
* Restore foreign-key-aware estimation of join relation sizes.Tom Lane2016-06-18
| | | | | | | | | | | | | | | | | | | | This patch provides a new implementation of the logic added by commit 137805f89 and later removed by 77ba61080. It differs from the original primarily in expending much less effort per joinrel in large queries, which it accomplishes by doing most of the matching work once per query not once per joinrel. Hopefully, it's also less buggy and better commented. The never-documented enable_fkey_estimates GUC remains gone. There remains work to be done to make the selectivity estimates account for nulls in FK referencing columns; but that was true of the original patch as well. We may be able to address this point later in beta. In the meantime, any error should be in the direction of overestimating rather than underestimating joinrel sizes, which seems like the direction we want to err in. Tomas Vondra and Tom Lane Discussion: <31041.1465069446@sss.pgh.pa.us>
* Still another try at fixing scanjoin_target insertion into parallel plans.Tom Lane2016-06-18
| | | | | | | | | | | The previous code neglected the fact that the scanjoin_target might carry sortgroupref labelings that we need to absorb. Instead, do create_projection_path() unconditionally, and tweak the path's cost estimate after the fact. (I'm now convinced that we ought to refactor the way we account for sometimes not needing a separate projection step, but right now is not the time for that sort of cleanup.) Problem identified by Amit Kapila, patch by me.
* Fix parallel-safety markings for contrib/dblink.Tom Lane2016-06-17
| | | | | | | | | | As shown by buildfarm reports, dblink_build_sql_insert and dblink_build_sql_update are *not* parallel safe, because they may attempt to access temporary tables of the local session. Although dblink_build_sql_delete doesn't actually touch the contents of the referenced table, it seems consistent and prudent to mark it PARALLEL RESTRICTED too.
* Fix handling of argument and result datatypes for partial aggregation.Tom Lane2016-06-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When doing partial aggregation, the args list of the upper (combining) Aggref node is replaced by a Var representing the output of the partial aggregation steps, which has either the aggregate's transition data type or a serialized representation of that. However, nodeAgg.c blindly continued to use the args list as an indication of the user-level argument types. This broke resolution of polymorphic transition datatypes at executor startup (though it accidentally failed to fail for the ANYARRAY case, which is likely the only one anyone had tested). Moreover, the constructed FuncExpr passed to the finalfunc contained completely wrong information, which would have led to bogus answers or crashes for any case where the finalfunc examined that information (which is only likely to be with polymorphic aggregates using a non-polymorphic transition type). As an independent bug, apply_partialaggref_adjustment neglected to resolve a polymorphic transition datatype before assigning it as the output type of the lower-level Aggref node. This again accidentally failed to fail for ANYARRAY but would be unlikely to work in other cases. To fix the first problem, record the user-level argument types in a separate OID-list field of Aggref, and look to that rather than the args list when asking what the argument types were. (It turns out to be convenient to include any "direct" arguments in this list too, although those are not currently subject to being overwritten.) Rather than adding yet another resolve_aggregate_transtype() call to fix the second problem, add an aggtranstype field to Aggref, and store the resolved transition type OID there when the planner first computes it. (By doing this in the planner and not the parser, we can allow the aggregate's transition type to change from time to time, although no DDL support yet exists for that.) This saves nothing of consequence for simple non-polymorphic aggregates, but for polymorphic transition types we save a catalog lookup during executor startup as well as several planner lookups that are new in 9.6 due to parallel query planning. In passing, fix an error that was introduced into count_agg_clauses_walker some time ago: it was applying exprTypmod() to something that wasn't an expression node at all, but a TargetEntry. exprTypmod silently returned -1 so that there was not an obvious failure, but this broke the intended sensitivity of aggregate space consumption estimates to the typmod of varchar and similar data types. This part needs to be back-patched. Catversion bump due to change of stored Aggref nodes. Discussion: <8229.1466109074@sss.pgh.pa.us>
* Docs typo fix.Tom Lane2016-06-17
| | | | Guillaume Lelarge
* Finish up XLOG_HINT renamingAlvaro Herrera2016-06-17
| | | | | | | Commit b8fd1a09f3 renamed XLOG_HINT to XLOG_FPI, but neglected two places. Backpatch to 9.3, like that commit.
* pg_visibility: Add pg_truncate_visibility_map function.Robert Haas2016-06-17
| | | | | | | | This requires some core changes as well so that we can properly WAL-log the truncation. Specifically, it changes the format of the XLOG_SMGR_TRUNCATE WAL record, so bump XLOG_PAGE_MAGIC. Patch by me, reviewed but not fully endorsed by Andres Freund.
* Try again to fix the way the scanjoin_target is used with partial paths.Robert Haas2016-06-17
| | | | | | | | | | | | | | | | Commit 04ae11f62e643e07c411c4935ea6af46cb112aa9 removed some broken code to apply the scan/join target to partial paths, but its theory that this processing step is totally unnecessary turns out to be wrong. Put similar code back again, but this time, check for parallel-safety and avoid in-place modifications to paths that may already have been used as part of some other path. (This is not an entirely elegant solution to this problem; it might be better, for example, to postpone generate_gather_paths for the topmost scan/join rel until after the scan/join target has been applied. But this is not the time for such redesign work.) Amit Kapila and Robert Haas
* Add VACUUM (DISABLE_PAGE_SKIPPING) for emergencies.Robert Haas2016-06-17
| | | | | | | | | | | | If you really want to vacuum every single page in the relation, regardless of apparent visibility status or anything else, you can use this option. In previous releases, this behavior could be achieved using VACUUM (FREEZE), but because we can now recognize all-frozen pages as not needing to be frozen again, that no longer works. There should be no need for routine use of this option, but maybe bugs or disaster recovery will necessitate its use. Patch by me, reviewed by Andres Freund.
* Update dblink extension for parallel query.Robert Haas2016-06-17
| | | | | | | | | | | | Almost all functions provided by this extension are PARALLEL RESTRICTED. Mostly, that's because the leader's TCP connections won't be shared with the workers, but in some cases like dblink_get_pkey it's because they obtain locks which might be released early if taken within a parallel worker. dblink_fdw_validator probably can't be used in a query anyway, but there would be no problem from the point of view of parallel query if it were, so it's PARALLEL SAFE. Andreas Karlsson
* postgres_fdw: Rephrase comment.Robert Haas2016-06-17
| | | | | Per gripe from Thomas Munro, who only complained about a more localized problem, but I couldn't resist a bit more wordsmithing.
* Fix typo.Robert Haas2016-06-17
| | | | Thomas Munro
* Remove PID from 'parallel worker' context message.Robert Haas2016-06-17
| | | | Discussion: <bfd204ab-ab1a-792a-b345-0274a09a4b5f@2ndquadrant.com>
* Attempt to fix broken regression test.Robert Haas2016-06-17
| | | | | | | | | | | | | | | In commit 8c1d9d56e9a00680a035b8b333a98ea16b121eb7, I attempted to add a regression test that would fail if the target list was pushed into a parallel worker, but due to brain fade on my part, it just randomly fails whether anything bad or not, because the error check inside the parallel_restricted() function tests whether there is *any process in the system* that is not connected to a client, not whether the process running the query is not connected to a client. A little experimentation has left me pessimistic about the prospects of doing better here in a short amount of time, so let's just fall back to checking that the plan is as we expect and leave the execution-time check for another day.
* Fix validation of overly-long IPv6 addresses.Tom Lane2016-06-16
| | | | | | | | | The inet/cidr types sometimes failed to reject IPv6 inputs with too many colon-separated fields, instead translating them to '::/0'. This is the result of a thinko in the original ISC code that seems to be as yet unreported elsewhere. Per bug #14198 from Stefan Kaltenbrunner. Report: <20160616182222.5798.959@wrigleys.postgresql.org>
* Fix fuzzy thinking in ReinitializeParallelDSM().Tom Lane2016-06-16
| | | | | | | | | The fact that no workers were successfully launched in the previous iteration does not excuse us from setting up properly to try again. This appears to explain crashes I saw in parallel regression testing due to error_mqh being NULL when it shouldn't be. Minor other cosmetic fixes too.
* Invent min_parallel_relation_size GUC to replace a hard-wired constant.Tom Lane2016-06-16
| | | | | | | | | | | | | | The main point of doing this is to allow the cutoff to be set very small, even zero, to allow parallel-query behavior to be tested on relatively small tables such as we typically use in the regression tests. But it might be of use to users too. The number-of-workers scaling behavior in create_plain_partial_paths() is pretty ad-hoc and subject to change, so we won't expose anything about that, but the notion of not considering parallel query at all for tables below size X seems reasonably stable. Amit Kapila, per a suggestion from me Discussion: <17170.1465830165@sss.pgh.pa.us>
* Reword bogus commentAlvaro Herrera2016-06-16
|
* Avoid crash in "postgres -C guc" for a GUC with a null string value.Tom Lane2016-06-16
| | | | | | | | | | Emit "(null)" instead, which was the behavior all along on platforms that don't crash, eg OS X. Per report from Jehan-Guillaume de Rorthais. Back-patch to 9.2 where -C option was introduced. Michael Paquier Report: <20160615204036.2d35d86a@firost>
* Remove unused prototypeAlvaro Herrera2016-06-16
| | | | | Commit 6f56b41ac0cd7 removed function get_pg_database_relfilenode but left its prototype in place. Remove it.
* Add regression test for 04ae11f62e643e07c411c4935ea6af46cb112aa9.Robert Haas2016-06-16
| | | | | | | The code in this area needs further revision, and it would be best not to re-break the things we've already fixed. Per a gripe from Tom Lane.
* Use strftime("%c") to format timestamps in psql's \watch command.Tom Lane2016-06-15
| | | | | | | | | | | | This allows the timestamps to follow local conventions (in particular, they respond to the LC_TIME environment setting). In C locale you get the same results as before. It seems like a good idea to do this now not later because we already changed the format of \watch headers for 9.6. Also, increase the buffer sizes a tad to ensure there's enough space for translated strings. Discussion: <20160612145532.GA22965@postgresql.kr>
* Fix regression test for force_parallel_mode=on.Robert Haas2016-06-15
| | | | | | | | Commit 14a254fb52423c57059851abafbd1247261f7f03 managed not to exercise the code it was intended to test, and the comment explaining why no "parallel worker" line showed up in the context wasn't right. Amit Kapila, tweaked by me per Amit's analysis.
* Add integrity-checking functions to pg_visibility.Robert Haas2016-06-15
| | | | | | | | | The new pg_check_visible() and pg_check_frozen() functions can be used to verify that the visibility map bits for a relation's data pages match the actual state of the tuples on those pages. Amit Kapila and Robert Haas, reviewed (in earlier versions) by Andres Freund. Additional testing help by Thomas Munro.
* Fix lazy_scan_heap so that it won't mark pages all-frozen too soon.Robert Haas2016-06-15
| | | | | | | | | | | | | Commit a892234f830e832110f63fc0a2afce2fb21d1584 added a new bit per page to the visibility map fork indicating whether the page is all-frozen, but incorrectly assumed that if lazy_scan_heap chose to freeze a tuple then that tuple would not need to later be frozen again. This turns out to be false, because xmin and xmax (and conceivably xvac, if dealing with tuples from very old releases) could be frozen at separate times. Thanks to Andres Freund for help in uncovering and tracking down this issue.
* Mark some functions parallel-unsafe.Robert Haas2016-06-15
| | | | | | | | | currtid() and currtid2() call GetLatestSnapshot(), which fails in parallel mode. pg_export_snapshot() calls ExportSnapshot() which attempts to assign an XID for the current transaction if it does not already have one; that, too, will fail in parallel mode. Andreas Seltenreich
* Force idle_in_transaction_session_timeout off in pg_dump and autovacuum.Tom Lane2016-06-15
| | | | | | | | | | | | | | | We disable statement_timeout and lock_timeout during dump and restore, to prevent any global settings that might exist from breaking routine backups. Commit c6dda1f48 should have added idle_in_transaction_session_timeout to that list, but failed to. Another place where these timeouts get turned off is autovacuum. While I doubt an idle timeout could fire there, it seems better to be safe than sorry. pg_dump issue noted by Bernd Helmle, the other one found by grepping. Report: <352F9B77DB5D3082578D17BB@eje.land.credativ.lan>
* PL/Python: Clean up extended error reporting docs and testsPeter Eisentraut2016-06-15
| | | | | Format the example and test code more to Python style standards. Improve whitespace. Improve documentation formatting.
* document when PREPARE uses generic plansBruce Momjian2016-06-14
| | | | | | | | | Also explain how generic plans are created. Link to PREPARE docs from wire-protocol prepare docs. Reported-by: Jonathan Rogers Discussion: https://www.postgresql.org/message-id/flat/561E749D.4090301%40socialserve.com
* Update xml2 extension for parallel query.Robert Haas2016-06-14
| | | | | | All functions provided by this extension are PARALLEL SAFE. Andreas Karlsson
* Update uuid-ossp extension for parallel query.Robert Haas2016-06-14
| | | | | | All functions provided by this extension are PARALLEL SAFE. Andreas Karlsson
* Update unaccent extension for parallel query.Robert Haas2016-06-14
| | | | | | All functions provided by this extension are PARALLEL SAFE. Andreas Karlsson
* Update sslinfo extension for parallel query.Robert Haas2016-06-14
| | | | | | | | | | All functions provided by this extension are PARALLEL RESTRICTED, because they provide information about the connection state. Parallel workers don't have this information and therefore these functions can't be executed in a worker (but they can be present in a query some other part of which uses parallelism). Andreas Karlsson
* Update extensions with GIN/GIST support for parallel query.Robert Haas2016-06-14
| | | | | | | | | | | | | | | | | | | | Commit 749a787c5b25ae33b3d4da0ef12aa05214aa73c7 bumped the extension version on all of these extensions already, and we haven't had a release since then, so we can make further changes without bumping the extension version again. Take this opportunity to mark all of the functions exported by these modules PARALLEL SAFE -- except for pg_trgm's set_limit(). Mark that one PARALLEL RESTRICTED, because it makes a persistent change to a GUC value. Note that some of the markings added by this commit don't have any effect; for example, gseg_picksplit() isn't likely to be mentioned explicitly in a query and therefore it's parallel-safety marking will never be consulted. But this commit just marks everything for consistency: if it were somehow used in a query, that would be fine as far as parallel query is concerned, since it does not consult any backend-private state, attempt to write data, etc. Andreas Karlsson, with a few revisions by me.
* postgres_fdw: Check PlaceHolderVars before pushing down a join.Robert Haas2016-06-14
| | | | | | | | | | | | | | | | | | | As discovered by Andreas Seltenreich via sqlsmith, it's possible for a remote join to need to generate a target list which contains a PlaceHolderVar which would need to be evaluated on the remote server. This happens when we try to push down a join tree which contains outer joins and the nullable side of the join contains a subquery which evauates some expression which can go to NULL above the level of the join. Since the deparsing logic can't build a remote query that involves subqueries, it fails while trying to produce an SQL query that can be sent to the remote side. Detect such cases and don't try to push down the join at all. It's actually fine to push down the join if the PlaceHolderVar needs to be evaluated at the current join level. This patch makes a small change to build_tlist_to_deparse so that this case will work. Amit Langote, Ashutosh Bapat, and me.
* Minor fixes in contrib installation scripts.Tom Lane2016-06-14
| | | | | | | | | | | | | | | | | | | Extension scripts should never use CREATE OR REPLACE for initial object creation. If there is a collision with a pre-existing (probably user-created) object, we want extension installation to fail, not silently overwrite the user's object. Bloom and sslinfo both violated this precept. Also fix a number of scripts that had no standard header (the file name comment and the \echo...\quit guard). Probably the \echo...\quit hack is less important now than it was in 9.1 days, but that doesn't mean that individual extensions get to choose whether to use it or not. And fix a couple of evident copy-and-pasteos in file name comments. No need for back-patch: the REPLACE bugs are both new in 9.6, and the rest of this is pretty much cosmetic. Andreas Karlsson and Tom Lane
* postgres_fdw: Promote an Assert() to elog().Robert Haas2016-06-14
| | | | | | | | | | Andreas Seltenreich reports that it is possible for a PlaceHolderVar to creep into this tlist, and I fear that even after that's fixed we might have other, similar bugs in this area either now or in the future. There's a lot of action-at-a-distance here, because the validity of this assertion depends on core planner behavior; so, let's use elog() to make sure we catch this even in non-assert builds, rather than just crashing.
* Fix multiple minor infelicities in aclchk.c error reports.Tom Lane2016-06-13
| | | | | | | | | | | | | | | | pg_type_aclmask reported the wrong type's OID when complaining that it could not find a type's typelem. It also failed to provide a suitable errcode when the initially given OID doesn't exist (which is a user-facing error, since that OID can be user-specified). pg_foreign_data_wrapper_aclmask and pg_foreign_server_aclmask likewise lacked errcode specifications. Trivial cosmetic adjustments too. The wrong-type-OID problem was reported by Petru-Florin Mihancea in bug #14186; the other issues noted by me while reading the code. These errors all seem to be aboriginal in the respective routines, so back-patch as necessary. Report: <20160613163159.5798.52928@wrigleys.postgresql.org>
* In planner.c, avoid assuming that all PathTargets have sortgrouprefs.Tom Lane2016-06-13
| | | | | | | | | | | | | The struct definition for PathTarget specifies that a NULL sortgrouprefs pointer means no sortgroupref labels. While it's likely that there should always be at least one labeled column in the places that were unconditionally fetching through the pointer, it seems wiser to adhere to the data structure specification and test first. Add a macro to make this convenient. Per experimentation with running the regression tests with a very small parallelization threshold --- the crash I observed may well represent a bug elsewhere, but still this coding was not very robust. Report: <20756.1465834072@sss.pgh.pa.us>
* Remove extraneous leading whitespace in Windows build script.Tom Lane2016-06-13
| | | | | | | | | Apparently, at least some versions of Microsoft's shell fail on variable assignments that have leading whitespace. This instance, introduced in commit 680513ab7, managed to escape notice for awhile because it's only invoked if building with OpenSSL. Per bug #14185 from Torben Dannhauer. Report: <20160613140119.5798.78501@wrigleys.postgresql.org>
* Finish pgindent run for 9.6: Perl files.Noah Misch2016-06-12
|
* Document the authoritative version of perltidy.Noah Misch2016-06-12
| | | | | Every whole-tree perltidy run has used this version, firmly establishing it as the de facto standard.
* PL/Python: Rename new keyword arguments of plpy.error() etc.Peter Eisentraut2016-06-11
| | | | | Rename schema -> schema_name etc. to remain consistent with C API and PL/pgSQL.
* Change default of backend_flush_after GUC to 0 (disabled).Andres Freund2016-06-10
| | | | | | | | | | | | | | | | | | | | | | | While beneficial, both for throughput and average/worst case latency, in a significant number of workloads, there are other workloads in which backend_flush_after can cause significant performance regressions in comparison to < 9.6 releases. The regression is most likely when the hot data set is bigger than shared buffers, but significantly smaller than the operating system's page cache. I personally think that the benefit of enabling backend flush control is considerably bigger than the potential downsides, but a fair argument can be made that not regressing is more important than improving performance/latency. As the latter is the consensus, change the default to 0. The other settings introduced in 428b1d6b2 do not have the same potential for regressions, so leave them enabled. Benchmarks leading up to changing the default have been performed by Mithun Cy, Ashutosh Sharma and Robert Haas. Discussion: CAD__OuhPmc6XH=wYRm_+Q657yQE88DakN4=Ybh2oveFasHkoeA@mail.gmail.com
* Remove reltarget_has_non_vars flag.Tom Lane2016-06-10
| | | | | | | | | | Commit b12fd41c6 added a "reltarget_has_non_vars" field to RelOptInfo, but failed to maintain it accurately. Since its only purpose was to skip calls to has_parallel_hazard() in the simple case where a rel's targetlist is all Vars, and that call is really pretty cheap in that case anyway, it seems like this is just a case of premature optimization. Let's drop the flag and do the calls unconditionally until it's proven that we need more smarts here.
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-05 09:38:27 +0000