| 9ed551e | Alvaro Herrera | 29 June 2016, 20:57:17 UTC | Add conninfo to pg_stat_wal_receiver Commit b1a9bad9e744 introduced a stats view to provide insight into the running WAL receiver, but neglected to include the connection string in it, as reported by Michaël Paquier. This commit fixes that omission. (Any security-sensitive information is not disclosed). While at it, close the mild security hole that we were exposing the password in the connection string in shared memory. This isn't user-accessible, but it still looks like a good idea to avoid having the cleartext password in memory. Author: Michaël Paquier, Álvaro Herrera Review by: Vik Fearing Discussion: https://www.postgresql.org/message-id/CAB7nPqStg4M561obo7ryZ5G+fUydG4v1Ajs1xZT1ujtu+woRag@mail.gmail.com | 29 June 2016, 20:57:17 UTC |
| b32e635 | Tom Lane | 29 June 2016, 20:02:08 UTC | Fix match_foreign_keys_to_quals for FKs linking to unused rtable entries. Since get_relation_foreign_keys doesn't try to determine whether RTEs are actually part of the query semantics, it might make FK info records linking to RTEs that won't have a RelOptInfo at all. Cope with that. Per bug #14219 from Andrew Gierth. Report: <20160629183338.1397.43514@wrigleys.postgresql.org> | 29 June 2016, 20:02:08 UTC |
| 4242a71 | Tom Lane | 29 June 2016, 19:00:25 UTC | Adjust text search documentation for recent commits. Fix some now-obsolete statements that were overlooked in commits 6734a1cac, 3dbbd0f02, 028350f61. Document the behavior of <0>. Also do a little bit of rearranging and copy-editing for clarity. | 29 June 2016, 19:00:33 UTC |
| 8dee039 | Robert Haas | 29 June 2016, 17:12:50 UTC | Fix obsolete comment. Commit 3bd261ca18c67eafe18088e58fab511e3b965418 should have updated this, but didn't. Extracted from a larger patch by Piotr Stefaniak. | 29 June 2016, 17:12:50 UTC |
| 73e6bea | Teodor Sigaev | 29 June 2016, 14:59:36 UTC | Document precedence of FTS operators in tsquery Oleg Bartunov | 29 June 2016, 14:59:36 UTC |
| 8a395e0 | Bruce Momjian | 28 June 2016, 20:16:06 UTC | doc: add link for list-of-scalars mention Reported-by: Manlio Perillo Bug: 14016 Discussion: 20160311163928.6674.94707@wrigleys.postgresql.org Reviewed-by: David G. Johnston | 28 June 2016, 20:16:06 UTC |
| 46eafc8 | Bruce Momjian | 28 June 2016, 20:09:04 UTC | doc: update effective_io_concurrency for SSDs SSDs are no longer exotic, so recommend a default in the hundreds for them. | 28 June 2016, 20:09:15 UTC |
| b78364d | Alvaro Herrera | 28 June 2016, 20:01:13 UTC | Remove unused arguments in two GiST subroutines These arguments became unused in commit 2c03216d8311. Noticed while skimming code for unrelated development. This is cosmetic, so no backpatch. | 28 June 2016, 20:01:13 UTC |
| 8e1ad1b | Bruce Momjian | 28 June 2016, 20:00:40 UTC | doc: remove GIN vs. GiST performance mention This is a followup to commit 6d8b2aa83af70e20323caf23961667dc4c149276. | 28 June 2016, 20:00:40 UTC |
| 69769a3 | Bruce Momjian | 28 June 2016, 18:21:43 UTC | doc: in binary mode mention, say "encoding conversion" Used to say "character set conversion" Reported-by: Tatsuo Ishii Discussion: 20160618.210417.343199294611427151.t-ishii@sraoss.co.jp | 28 June 2016, 18:21:43 UTC |
| 675684f | Bruce Momjian | 28 June 2016, 17:49:37 UTC | doc: remove mention of UT1 in representing time UT1 was incorrectly specified as our time representation. (UT1 is astronomical time.) We are not actually UTC either because we ignore leap seconds. Reported-by: Thomas Munro Discussion: CAEepm=3-TW9PLwGZhqjSSiEQ9UzJEKE-HELQDzRE0QUSCp8dgw@mail.gmail.com | 28 June 2016, 17:49:37 UTC |
| c12f02f | Tom Lane | 28 June 2016, 14:43:11 UTC | Don't apply sortgroupref labels to a tlist that might not match. If we need to use a gating Result node for pseudoconstant quals, create_scan_plan() intentionally suppresses use_physical_tlist's checks on whether there are matches for sortgroupref labels, on the grounds that we don't need matches because we can label the Result's projection output properly. However, it then called apply_pathtarget_labeling_to_tlist anyway. This oversight was harmless when written, but in commit aeb9ae645 I made that function throw an error if there was no match. Thus, the combination of a table scan, pseudoconstant quals, and a non-simple-Var sortgroupref column threw the dreaded "ORDER/GROUP BY expression not found in targetlist" error. To fix, just skip applying the labeling in this case. Per report from Rushabh Lathia. Report: <CAGPqQf2iLB8t6t-XrL-zR233DFTXxEsfVZ4WSqaYfLupEoDxXA@mail.gmail.com> | 28 June 2016, 14:43:11 UTC |
| 957616d | Robert Haas | 27 June 2016, 21:54:28 UTC | Fix mistakes in pg_visibility documentation. Michael Paquier | 27 June 2016, 21:55:03 UTC |
| 874fe3a | Tom Lane | 27 June 2016, 19:57:21 UTC | Fix CREATE MATVIEW/CREATE TABLE AS ... WITH NO DATA to not plan the query. Previously, these commands always planned the given query and went through executor startup before deciding not to actually run the query if WITH NO DATA is specified. This behavior is problematic for pg_dump because it may cause errors to be raised that we would rather not see before a REFRESH MATERIALIZED VIEW command is issued. See for example bug #13907 from Marian Krucina. This change is not sufficient to fix that particular bug, because we also need to tweak pg_dump to issue the REFRESH later, but it's a necessary step on the way. A user-visible side effect of doing things this way is that the returned command tag for WITH NO DATA cases will now be "CREATE MATERIALIZED VIEW" or "CREATE TABLE AS", not "SELECT 0". We could preserve the old behavior but it would take more code, and arguably that was just an implementation artifact not intended behavior anyhow. In 9.5 and HEAD, also get rid of the static variable CreateAsReladdr, which was trouble waiting to happen; there is not any prohibition on nested CREATE commands. Back-patch to 9.3 where CREATE MATERIALIZED VIEW was introduced. Michael Paquier and Tom Lane Report: <20160202161407.2778.24659@wrigleys.postgresql.org> | 27 June 2016, 19:57:50 UTC |
| 6734a1c | Teodor Sigaev | 27 June 2016, 17:55:24 UTC | Change predecence of phrase operator. <-> operator now have higher predecence than & (AND) operator. This change was motivated by unexpected difference of similar queries: 'a & b <-> c'::tsquery and 'b <-> c & a'. Before first query means (a & b) <-> c and second one - '(b <-> c) & a', now phrase operator evaluates first. Per suggestion from Tom Lane 32260.1465402409@sss.pgh.pa.us | 27 June 2016, 17:55:24 UTC |
| 3dbbd0f | Teodor Sigaev | 27 June 2016, 17:47:32 UTC | Do not fallback to AND for FTS phrase operator. If there is no positional information of lexemes then phrase operator will not fallback to AND operator. This change makes needing to modify TS_execute() interface, because somewhere (in indexes, for example) positional information is unaccesible and in this cases we need to force fallback to AND. Per discussion c19fcfec308e6ccd952cdde9e648b505@mail.gmail.com | 27 June 2016, 17:47:32 UTC |
| 028350f | Teodor Sigaev | 27 June 2016, 17:41:00 UTC | Make exact distance match for FTS phrase operator Phrase operator now requires exact distance betweens lexems instead of less-or-equal. Per discussion c19fcfec308e6ccd952cdde9e648b505@mail.gmail.com | 27 June 2016, 17:41:00 UTC |
| f199303 | Tom Lane | 26 June 2016, 19:55:01 UTC | Avoid making a separate pass over the query to check for partializability. It's rather silly to make a separate pass over the tlist + HAVING qual, and a separate set of visits to the syscache, when get_agg_clause_costs already has all the required information in hand. This nets out as less code as well as fewer cycles. | 26 June 2016, 19:55:01 UTC |
| 19e972d | Tom Lane | 26 June 2016, 18:33:38 UTC | Rethink node-level representation of partial-aggregation modes. The original coding had three separate booleans representing partial aggregation behavior, which was confusing, unreadable, and error-prone, not least because the booleans weren't always listed in the same order. It was also inadequate for the allegedly-desirable future extension to support intermediate partial aggregation, because we'd need separate markers for serialization and deserialization in such a case. Merge these bools into an enum "AggSplit" to provide symbolic names for the supported operating modes (and document what those are). By assigning the values of the enum constants carefully, we can treat AggSplit values as options bitmasks so that tests of what to do aren't noticeably more expensive than before. While at it, get rid of Aggref.aggoutputtype. That's not needed since commit 59a3795c2 got rid of setrefs.c's special-purpose Aggref comparison code, and it likewise seemed more confusing than helpful. Assorted comment cleanup as well (there's still more that I want to do in that line). catversion bump for change in Aggref node contents. Should be the last one for partial-aggregation changes. Discussion: <29309.1466699160@sss.pgh.pa.us> | 26 June 2016, 18:33:38 UTC |
| 59a3795 | Tom Lane | 26 June 2016, 16:08:12 UTC | Simplify planner's final setup of Aggrefs for partial aggregation. Commit e06a38965's original coding for constructing the execution-time expression tree for a combining aggregate was rather messy, involving duplicating quite a lot of code in setrefs.c so that it could inject a nonstandard matching rule for Aggrefs. Get rid of that in favor of explicitly constructing a combining Aggref with a partial Aggref as input, then allowing setref's normal matching logic to match the partial Aggref to the output of the lower plan node and hence replace it with a Var. In passing, rename and redocument make_partialgroup_input_target to have some connection to what it actually does. | 26 June 2016, 16:08:12 UTC |
| e3ad3ff | Alvaro Herrera | 24 June 2016, 22:29:28 UTC | Fix handling of multixacts predating pg_upgrade After pg_upgrade, it is possible that some tuples' Xmax have multixacts corresponding to the old installation; such multixacts cannot have running members anymore. In many code sites we already know not to read them and clobber them silently, but at least when VACUUM tries to freeze a multixact or determine whether one needs freezing, there's an attempt to resolve it to its member transactions by calling GetMultiXactIdMembers, and if the multixact value is "in the future" with regards to the current valid multixact range, an error like this is raised: ERROR: MultiXactId 123 has not been created yet -- apparent wraparound and vacuuming fails. Per discussion with Andrew Gierth, it is completely bogus to try to resolve multixacts coming from before a pg_upgrade, regardless of where they stand with regards to the current valid multixact range. It's possible to get from under this problem by doing SELECT FOR UPDATE of the problem tuples, but if tables are large, this is slow and tedious, so a more thorough solution is desirable. To fix, we realize that multixacts in xmax created in 9.2 and previous have a specific bit pattern that is never used in 9.3 and later (we already knew this, per comments and infomask tests sprinkled in various places, but we weren't leveraging this knowledge appropriately). Whenever the infomask of the tuple matches that bit pattern, we just ignore the multixact completely as if Xmax wasn't set; or, in the case of tuple freezing, we act as if an unwanted value is set and clobber it without decoding. This guarantees that no errors will be raised, and that the values will be progressively removed until all tables are clean. Most callers of GetMultiXactIdMembers are patched to recognize directly that the value is a removable "empty" multixact and avoid calling GetMultiXactIdMembers altogether. To avoid changing the signature of GetMultiXactIdMembers() in back branches, we keep the "allow_old" boolean flag but rename it to "from_pgupgrade"; if the flag is true, we always return an empty set instead of looking up the multixact. (I suppose we could remove the argument in the master branch, but I chose not to do so in this commit). This was broken all along, but the error-facing message appeared first because of commit 8e9a16ab8f7f and was partially fixed in a25c2b7c4db3. This fix, backpatched all the way back to 9.3, goes approximately in the same direction as a25c2b7c4db3 but should cover all cases. Bug analysis by Andrew Gierth and Álvaro Herrera. A number of public reports match this bug: https://www.postgresql.org/message-id/20140330040029.GY4582@tamriel.snowman.net https://www.postgresql.org/message-id/538F3D70.6080902@publicrelay.com https://www.postgresql.org/message-id/556439CF.7070109@pscs.co.uk https://www.postgresql.org/message-id/SG2PR06MB0760098A111C88E31BD4D96FB3540@SG2PR06MB0760.apcprd06.prod.outlook.com https://www.postgresql.org/message-id/20160615203829.5798.4594@wrigleys.postgresql.org | 24 June 2016, 22:29:28 UTC |
| 8cf739d | Tom Lane | 24 June 2016, 20:57:36 UTC | Fix building of large (bigger than shared_buffers) hash indexes. When the index is predicted to need more than NBuffers buckets, CREATE INDEX attempts to sort the index entries by hash key before insertion, so as to reduce thrashing. This code path got broken by commit 9f03ca915196dfc8, which overlooked that _hash_form_tuple() is not just an alias for index_form_tuple(). The index got built anyway, but with garbage data, so that searches for pre-existing tuples always failed. Fix by refactoring to separate construction of the indexable data from calling index_form_tuple(). Per bug #14210 from Daniel Newman. Back-patch to 9.5 where the bug was introduced. Report: <20160623162507.17237.39471@wrigleys.postgresql.org> | 24 June 2016, 20:57:36 UTC |
| 9e9c38e | Robert Haas | 24 June 2016, 19:06:19 UTC | postgres_fdw: Fix incorrect NULL handling in join pushdown. something.* IS NOT NULL means that every attribute of the row is not NULL, not that the row itself is non-NULL (e.g. because it's coming from below an outer join. Use (somevar.*)::pg_catalog.text IS NOT NULL instead. Ashutosh Bapat, per a report by Rushabh Lathia. Reviewed by Amit Langote and Etsuro Fujita. Schema-qualification added by me. | 24 June 2016, 19:14:15 UTC |
| 267569b | Robert Haas | 24 June 2016, 18:32:11 UTC | postgres_fdw: Remove useless return statement. Etsuro Fujita | 24 June 2016, 18:33:13 UTC |
| bd406af | Peter Eisentraut | 24 June 2016, 05:08:08 UTC | psql: Improve \crosstabview error messages | 24 June 2016, 05:08:08 UTC |
| 562e449 | Andrew Dunstan | 23 June 2016, 20:10:15 UTC | Add tab completion for pager_min_lines to psql. This was inadvertantly omitted from commit 7655f4ccea570d57c4d473cd66b755c03c904942. Mea culpa. Backpatched to 9.5 where pager_min_lines was introduced. | 23 June 2016, 20:10:15 UTC |
| bd1693e | Tom Lane | 23 June 2016, 14:55:59 UTC | Fix small memory leak in partial-aggregate deserialization functions. A deserialize function's result is short-lived data during partial aggregation, since we're just going to pass it to the combine function and then it's of no use anymore. However, the built-in deserialize functions allocated their results in the aggregate state context, resulting in a query-lifespan memory leak. It's probably not possible for this to amount to anything much at present, since the number of leaked results would only be the number of worker processes. But it might become a problem in future. To fix, don't use the same convenience subroutine for setting up results that the aggregate transition functions use. David Rowley Report: <10050.1466637736@sss.pgh.pa.us> | 23 June 2016, 14:55:59 UTC |
| 2d67342 | Tom Lane | 22 June 2016, 23:14:16 UTC | Improve user-facing documentation for partial/parallel aggregation. Add a section to xaggr.sgml, as we have done in the past for other extensions to the aggregation functionality. Assorted wordsmithing and other minor improvements. David Rowley and Tom Lane | 22 June 2016, 23:14:16 UTC |
| 63ae052 | Tom Lane | 22 June 2016, 21:12:55 UTC | Update oidjoins regression test for 9.6. Looks like we had some more catalog drift recently. | 22 June 2016, 21:12:55 UTC |
| f8ace54 | Tom Lane | 22 June 2016, 20:52:41 UTC | Fix type-safety problem with parallel aggregate serial/deserialization. The original specification for this called for the deserialization function to have signature "deserialize(serialtype) returns transtype", which is a security violation if transtype is INTERNAL (which it always would be in practice) and serialtype is not (which ditto). The patch blithely overrode the opr_sanity check for that, which was sloppy-enough work in itself, but the indisputable reason this cannot be allowed to stand is that CREATE FUNCTION will reject such a signature and thus it'd be impossible for extensions to create parallelizable aggregates. The minimum fix to make the signature type-safe is to add a second, dummy argument of type INTERNAL. But to lock it down a bit more and make misuse of INTERNAL-accepting functions less likely, let's get rid of the ability to specify a "serialtype" for an aggregate and just say that the only useful serialtype is BYTEA --- which, in practice, is the only interesting value anyway, due to the usefulness of the send/recv infrastructure for this purpose. That means we only have to allow "serialize(internal) returns bytea" and "deserialize(bytea, internal) returns internal" as the signatures for these support functions. In passing fix bogus signature of int4_avg_combine, which I found thanks to adding an opr_sanity check on combinefunc signatures. catversion bump due to removing pg_aggregate.aggserialtype and adjusting signatures of assorted built-in functions. David Rowley and Tom Lane Discussion: <27247.1466185504@sss.pgh.pa.us> | 22 June 2016, 20:52:41 UTC |
| e45e990 | Tom Lane | 22 June 2016, 15:55:18 UTC | Make "postgres -C guc" print "" not "(null)" for null-valued GUCs. Commit 0b0baf262 et al made this case print "(null)" on the grounds that that's what happened on platforms that didn't crash. But neither behavior was actually intentional. What we should print is just an empty string, for compatibility with the behavior of SHOW and other ways of examining string GUCs. Those code paths don't distinguish NULL from empty strings, so we should not here either. Per gripe from Alain Radix. Like the previous patch, back-patch to 9.2 where -C option was introduced. Discussion: <CA+YdpwxPUADrmxSD7+Td=uOshMB1KkDN7G7cf+FGmNjjxMhjbw@mail.gmail.com> | 22 June 2016, 15:55:18 UTC |
| 6a9c518 | Peter Eisentraut | 22 June 2016, 01:52:35 UTC | Improve cleanup in rolenames test Drop test_schema at the end, because that otherwise interferes with the collate.linux.utf8 test. | 22 June 2016, 01:52:35 UTC |
| 3e9df85 | Bruce Momjian | 22 June 2016, 00:23:20 UTC | Update comment about allowing GUCs to change scanning. Reported-by: David G. Johnston Discussion: CAKFQuwZZvnxwSq9tNtvL+uyuDKGgV91zR_agtPxQHRWMWQRP8g@mail.gmail.com | 22 June 2016, 00:23:31 UTC |
| 3429210 | Tom Lane | 22 June 2016, 00:07:58 UTC | Document that dependency tracking doesn't consider function bodies. If there's anyplace in our SGML docs that explains this behavior, I can't find it right at the moment. Add an explanation in "Dependency Tracking" which seems like the authoritative place for such a discussion. Per gripe from Michelle Schwan. While at it, update this section's example of a dependency-related error message: they last looked like that in 8.3. And remove the explanation of dependency updates from pre-7.3 installations, which is probably no longer worth anybody's brain cells to read. The bogus error message example seems like an actual documentation bug, so back-patch to all supported branches. Discussion: <20160620160047.5792.49827@wrigleys.postgresql.org> | 22 June 2016, 00:07:58 UTC |
| 8b9d323 | Tom Lane | 21 June 2016, 22:38:20 UTC | Refactor planning of projection steps that don't need a Result plan node. The original upper-planner-pathification design (commit 3fc6e2d7f5b652b4) assumed that we could always determine during Path formation whether or not we would need a Result plan node to perform projection of a targetlist. That turns out not to work very well, though, because createplan.c still has some responsibilities for choosing the specific target list associated with sorting/grouping nodes (in particular it might choose to add resjunk columns for sorting). We might not ever refactor that --- doing so would push more work into Path formation, which isn't attractive --- and we certainly won't do so for 9.6. So, while create_projection_path and apply_projection_to_path can tell for sure what will happen if the subpath is projection-capable, they can't tell for sure when it isn't. This is at least a latent bug in apply_projection_to_path, which might think it can apply a target to a non-projecting node when the node will end up computing something different. Also, I'd tied the creation of a ProjectionPath node to whether or not a Result is needed, but it turns out that we sometimes need a ProjectionPath node anyway to avoid modifying a possibly-shared subpath node. Callers had to use create_projection_path for such cases, and we added code to them that knew about the potential omission of a Result node and attempted to adjust the cost estimates for that. That was uncertainly correct and definitely ugly/unmaintainable. To fix, have create_projection_path explicitly check whether a Result is needed and adjust its cost estimate accordingly, though it creates a ProjectionPath in either case. apply_projection_to_path is now mostly just an optimized version that can avoid creating an extra Path node when the input is known to not be shared with any other live path. (There is one case that create_projection_path doesn't handle, which is pushing parallel-safe expressions below a Gather node. We could make it do that by duplicating the GatherPath, but there seems no need as yet.) create_projection_plan still has to recheck the tlist-match condition, which means that if the matching situation does get changed by createplan.c then we'll have made a slightly incorrect cost estimate. But there seems no help for that in the near term, and I doubt it occurs often enough, let alone would change planning decisions often enough, to be worth stressing about. I added a "dummypp" field to ProjectionPath to track whether create_projection_path thinks a Result is needed. This is not really necessary as-committed because create_projection_plan doesn't look at the flag; but it seems like a good idea to remember what we thought when forming the cost estimate, if only for debugging purposes. In passing, get rid of the target_parallel parameter added to apply_projection_to_path by commit 54f5c5150. I don't think that's a good idea because it involves callers in what should be an internal decision, and opens us up to missing optimization opportunities if callers think they don't need to provide a valid flag, as most don't. For the moment, this just costs us an extra has_parallel_hazard call when planning a Gather. If that starts to look expensive, I think a better solution would be to teach PathTarget to carry/cache knowledge of parallel-safety of its contents. | 21 June 2016, 22:38:20 UTC |
| 936b62d | Tom Lane | 20 June 2016, 20:23:47 UTC | Stamp 9.6beta2. | 20 June 2016, 20:23:47 UTC |
| 1fe1204 | Tom Lane | 20 June 2016, 19:36:54 UTC | Add missing check for malloc failure in plpgsql_extra_checks_check_hook(). Per report from Andreas Seltenreich. Back-patch to affected versions. Report: <874m8nn0hv.fsf@elite.ansel.ydns.eu> | 20 June 2016, 19:36:54 UTC |
| e611515 | Tom Lane | 20 June 2016, 15:29:47 UTC | pg_trgm's set_limit() function is parallel unsafe, not parallel restricted. Per buildfarm. Fortunately, it's not quite too late to squeeze this fix into the pg_trgm 1.3 update. | 20 June 2016, 15:29:54 UTC |
| 3557b17 | Bruce Momjian | 20 June 2016, 15:09:21 UTC | docs: clarify use of pg_rewind arguments Specifically, --source-pgdata and --source-server. Discussion: 20160617155108.GC19359@momjian.us Reviewed-by: Michael Paquier | 20 June 2016, 15:09:21 UTC |
| 9c85256 | Tom Lane | 20 June 2016, 14:49:19 UTC | Fix comparison of similarity to threshold in GIST trigram searches. There was some very strange code here, dating to commit b525bf77, that purported to work around an ancient gcc bug by forcing a float4 comparison to be done as int instead. Commit 5871b8848 broke that when it changed one side of the comparison to "double" but left the comparison code alone. Commit f576b17cd doubled down on the weirdness by introducing a "volatile" marker, which had nothing to do with the actual problem. Guess that the gcc bug, even if it's still present in the wild, was triggered by comparison of float4's and can be avoided if we store the result of cnt_sml() into a double before comparing to the double "nlimit". This will at least work correctly on non-broken compilers, and it's way more readable. Per bug #14202 from Greg Navis. Add a regression test based on his example. Report: <20160620115321.5792.10766@wrigleys.postgresql.org> | 20 June 2016, 14:49:19 UTC |
| 47981a4 | Peter Eisentraut | 20 June 2016, 13:48:08 UTC | Translation updates Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 0c374f8d25ed31833a10d24252bc928d41438838 | 20 June 2016, 13:48:08 UTC |
| 4d48adc | Magnus Hagander | 20 June 2016, 08:29:20 UTC | Add missing documentation of pg_roles.rolbypassrls Noted by Lukas Fittl | 20 June 2016, 08:29:20 UTC |
| 705ad7f | Tom Lane | 19 June 2016, 17:11:40 UTC | Docs: improve description of psql's %R prompt escape sequence. 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> | 19 June 2016, 17:11:40 UTC |
| 9bc3332 | Tom Lane | 18 June 2016, 23:38:59 UTC | Improve error message annotation for GRANT/REVOKE on untrusted PLs. 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> | 18 June 2016, 23:38:59 UTC |
| a3f42e8 | Tom Lane | 18 June 2016, 22:05:27 UTC | Update 9.6 release notes through today. | 18 June 2016, 22:05:27 UTC |
| 100340e | Tom Lane | 18 June 2016, 19:22:34 UTC | Restore foreign-key-aware estimation of join relation sizes. 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> | 18 June 2016, 19:22:34 UTC |
| 598aa19 | Tom Lane | 18 June 2016, 04:28:51 UTC | Still another try at fixing scanjoin_target insertion into parallel plans. 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. | 18 June 2016, 04:28:51 UTC |
| 7e81a18 | Tom Lane | 18 June 2016, 03:08:21 UTC | Fix parallel-safety markings for contrib/dblink. 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. | 18 June 2016, 03:08:21 UTC |
| 915b703 | Tom Lane | 18 June 2016, 01:44:37 UTC | Fix handling of argument and result datatypes for partial aggregation. 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> | 18 June 2016, 01:44:37 UTC |
| d30d1ac | Tom Lane | 17 June 2016, 22:23:39 UTC | Docs typo fix. Guillaume Lelarge | 17 June 2016, 22:23:39 UTC |
| 1ca4a1b | Alvaro Herrera | 17 June 2016, 22:05:55 UTC | Finish up XLOG_HINT renaming Commit b8fd1a09f3 renamed XLOG_HINT to XLOG_FPI, but neglected two places. Backpatch to 9.3, like that commit. | 17 June 2016, 22:05:55 UTC |
| 71d05a2 | Robert Haas | 17 June 2016, 21:37:30 UTC | pg_visibility: Add pg_truncate_visibility_map function. 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. | 17 June 2016, 21:37:30 UTC |
| 54f5c51 | Robert Haas | 17 June 2016, 20:25:02 UTC | Try again to fix the way the scanjoin_target is used with partial paths. 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 | 17 June 2016, 20:29:07 UTC |
| ede62e5 | Robert Haas | 17 June 2016, 19:48:57 UTC | Add VACUUM (DISABLE_PAGE_SKIPPING) for emergencies. 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. | 17 June 2016, 19:48:57 UTC |
| 20eb273 | Robert Haas | 17 June 2016, 19:09:57 UTC | Update dblink extension for parallel query. 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 | 17 June 2016, 19:18:44 UTC |
| 177c56d | Robert Haas | 17 June 2016, 17:01:14 UTC | postgres_fdw: Rephrase comment. Per gripe from Thomas Munro, who only complained about a more localized problem, but I couldn't resist a bit more wordsmithing. | 17 June 2016, 17:02:22 UTC |
| 9c188a8 | Robert Haas | 17 June 2016, 16:55:30 UTC | Fix typo. Thomas Munro | 17 June 2016, 16:55:30 UTC |
| 292794f | Robert Haas | 17 June 2016, 13:24:29 UTC | Remove PID from 'parallel worker' context message. Discussion: <bfd204ab-ab1a-792a-b345-0274a09a4b5f@2ndquadrant.com> | 17 June 2016, 13:26:17 UTC |
| 103512c | Robert Haas | 17 June 2016, 12:35:47 UTC | Attempt to fix broken regression test. 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. | 17 June 2016, 12:35:47 UTC |
| 4c56f32 | Tom Lane | 16 June 2016, 21:16:32 UTC | Fix validation of overly-long IPv6 addresses. 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> | 16 June 2016, 21:16:32 UTC |
| bfb9374 | Tom Lane | 16 June 2016, 19:20:29 UTC | Fix fuzzy thinking in ReinitializeParallelDSM(). 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. | 16 June 2016, 19:20:29 UTC |
| 75be664 | Tom Lane | 16 June 2016, 17:47:20 UTC | Invent min_parallel_relation_size GUC to replace a hard-wired constant. 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> | 16 June 2016, 17:47:20 UTC |
| 3b5a2a8 | Alvaro Herrera | 16 June 2016, 16:43:35 UTC | Reword bogus comment | 16 June 2016, 16:43:35 UTC |
| 0b0baf2 | Tom Lane | 16 June 2016, 16:17:03 UTC | Avoid crash in "postgres -C guc" for a GUC with a null string value. 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> | 16 June 2016, 16:17:38 UTC |
| b000afe | Alvaro Herrera | 16 June 2016, 16:06:51 UTC | Remove unused prototype Commit 6f56b41ac0cd7 removed function get_pg_database_relfilenode but left its prototype in place. Remove it. | 16 June 2016, 16:06:51 UTC |
| 8c1d9d5 | Robert Haas | 16 June 2016, 16:00:55 UTC | Add regression test for 04ae11f62e643e07c411c4935ea6af46cb112aa9. 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. | 16 June 2016, 16:00:55 UTC |
| 9901d8a | Tom Lane | 15 June 2016, 23:31:08 UTC | Use strftime("%c") to format timestamps in psql's \watch command. 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> | 15 June 2016, 23:31:13 UTC |
| 12f8620 | Robert Haas | 15 June 2016, 18:59:07 UTC | Fix regression test for force_parallel_mode=on. 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. | 15 June 2016, 18:59:07 UTC |
| e472ce9 | Robert Haas | 15 June 2016, 18:33:58 UTC | Add integrity-checking functions to pg_visibility. 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. | 15 June 2016, 18:33:58 UTC |
| 38e9f90 | Robert Haas | 15 June 2016, 18:23:39 UTC | Fix lazy_scan_heap so that it won't mark pages all-frozen too soon. 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. | 15 June 2016, 18:30:06 UTC |
| c7a25c2 | Robert Haas | 15 June 2016, 15:40:07 UTC | Mark some functions parallel-unsafe. 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 | 15 June 2016, 15:40:07 UTC |
| 8383486 | Tom Lane | 15 June 2016, 14:52:53 UTC | Force idle_in_transaction_session_timeout off in pg_dump and autovacuum. 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> | 15 June 2016, 14:53:03 UTC |
| f0688d6 | Peter Eisentraut | 15 June 2016, 14:34:11 UTC | PL/Python: Clean up extended error reporting docs and tests Format the example and test code more to Python style standards. Improve whitespace. Improve documentation formatting. | 15 June 2016, 14:34:11 UTC |
| fab9d1d | Bruce Momjian | 14 June 2016, 20:11:46 UTC | document when PREPARE uses generic plans 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 | 14 June 2016, 20:11:48 UTC |
| 13e7453 | Robert Haas | 14 June 2016, 19:49:32 UTC | Update xml2 extension for parallel query. All functions provided by this extension are PARALLEL SAFE. Andreas Karlsson | 14 June 2016, 19:49:32 UTC |
| 20f6c3a | Robert Haas | 14 June 2016, 18:56:21 UTC | Update uuid-ossp extension for parallel query. All functions provided by this extension are PARALLEL SAFE. Andreas Karlsson | 14 June 2016, 18:56:21 UTC |
| 202ac08 | Robert Haas | 14 June 2016, 18:55:49 UTC | Update unaccent extension for parallel query. All functions provided by this extension are PARALLEL SAFE. Andreas Karlsson | 14 June 2016, 18:55:49 UTC |
| 6b7d11f | Robert Haas | 14 June 2016, 18:52:55 UTC | Update sslinfo extension for parallel query. 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 | 14 June 2016, 18:52:55 UTC |
| 2910fc8 | Robert Haas | 14 June 2016, 17:34:37 UTC | Update extensions with GIN/GIST support for parallel query. 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. | 14 June 2016, 17:34:37 UTC |
| 131c7e7 | Robert Haas | 14 June 2016, 15:48:27 UTC | postgres_fdw: Check PlaceHolderVars before pushing down a join. 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. | 14 June 2016, 15:48:27 UTC |
| 5484c0a | Tom Lane | 14 June 2016, 14:47:06 UTC | Minor fixes in contrib installation scripts. 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 | 14 June 2016, 14:47:06 UTC |
| 332fdbe | Robert Haas | 14 June 2016, 12:55:50 UTC | postgres_fdw: Promote an Assert() to elog(). 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. | 14 June 2016, 13:00:12 UTC |
| 783cb6e | Tom Lane | 13 June 2016, 17:53:10 UTC | Fix multiple minor infelicities in aclchk.c error reports. 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> | 13 June 2016, 17:53:10 UTC |
| 89d5351 | Tom Lane | 13 June 2016, 16:59:25 UTC | In planner.c, avoid assuming that all PathTargets have sortgrouprefs. 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> | 13 June 2016, 16:59:25 UTC |
| cd9b4f2 | Tom Lane | 13 June 2016, 15:50:27 UTC | Remove extraneous leading whitespace in Windows build script. 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> | 13 June 2016, 15:50:27 UTC |
| 3be0a62 | Noah Misch | 12 June 2016, 08:19:56 UTC | Finish pgindent run for 9.6: Perl files. | 12 June 2016, 08:19:56 UTC |
| b098abf | Noah Misch | 12 June 2016, 08:19:44 UTC | Document the authoritative version of perltidy. Every whole-tree perltidy run has used this version, firmly establishing it as the de facto standard. | 12 June 2016, 08:19:44 UTC |
| 020140d | Peter Eisentraut | 11 June 2016, 23:27:49 UTC | PL/Python: Rename new keyword arguments of plpy.error() etc. Rename schema -> schema_name etc. to remain consistent with C API and PL/pgSQL. | 11 June 2016, 23:27:49 UTC |
| 4bc0f16 | Andres Freund | 10 June 2016, 22:31:11 UTC | Change default of backend_flush_after GUC to 0 (disabled). 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 | 10 June 2016, 22:31:11 UTC |
| 3303ea1 | Tom Lane | 10 June 2016, 20:20:03 UTC | Remove reltarget_has_non_vars flag. 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. | 10 June 2016, 20:20:03 UTC |
| 2f153dd | Tom Lane | 10 June 2016, 20:03:37 UTC | Refactor to reduce code duplication for function property checking. As noted by Andres Freund, we'd accumulated quite a few similar functions in clauses.c that examine all functions in an expression tree to see if they satisfy some boolean test. Reduce the duplication by inventing a function check_functions_in_node() that applies a simple callback function to each SQL function OID appearing in a given expression node. This also fixes some arguable oversights; for example, contain_mutable_functions() did not check aggregate or window functions for mutability. I doubt that that represents a live bug at the moment, because we don't really consider mutability for aggregates; but it might someday be one. I chose to put check_functions_in_node() in nodeFuncs.c because it seemed like other modules might wish to use it in future. That in turn forced moving set_opfuncid() et al into nodeFuncs.c, as the alternative was for nodeFuncs.c to depend on optimizer/setrefs.c which didn't seem very clean. In passing, teach contain_leaked_vars_walker() about a few more expression node types it can safely look through, and improve the rather messy and undercommented code in has_parallel_hazard_walker(). Discussion: <20160527185853.ziol2os2zskahl7v@alap3.anarazel.de> | 10 June 2016, 20:03:46 UTC |
| 13761bc | Kevin Grittner | 10 June 2016, 16:24:01 UTC | Rename local variable for consistency. Pointed out by Robert Haas. | 10 June 2016, 16:24:01 UTC |
| a8501ba | Robert Haas | 10 June 2016, 14:42:03 UTC | Update pgstattuple extension for parallel query. All functions provided by this extension are PARALLEL SAFE. Andreas Karlsson | 10 June 2016, 14:42:03 UTC |
| 496899c | Robert Haas | 10 June 2016, 14:42:01 UTC | Update pg_stat_statements extension for parallel query. All functions provided by this extension are PARALLEL SAFE. Given the general prohibition against write operations in parallel queries, it is perhaps a bit surprising that pg_stat_statements_reset() is parallel safe. But since it only modifies shared memory, not the database, it's OK. Andreas Karlsson | 10 June 2016, 14:42:01 UTC |
| 3d8fc8c | Robert Haas | 10 June 2016, 14:41:58 UTC | Schema-qualify some references to regprocedure. Andreas Karlsson, per a gripe from Tom Lane. | 10 June 2016, 14:41:58 UTC |
| bf9a60e | Kevin Grittner | 10 June 2016, 14:25:31 UTC | Fix interaction between CREATE INDEX and "snapshot too old". Since indexes are created without valid LSNs, an index created while a snapshot older than old_snapshot_threshold existed could cause queries to return incorrect results when those old snapshots were used, if any relevant rows had been subject to early pruning before the index was built. Prevent usage of a newly created index until all such snapshots are released, for relations where this can happen. Questions about the interaction of "snapshot too old" with index creation were initially raised by Andres Freund. Reviewed by Robert Haas. | 10 June 2016, 14:25:31 UTC |
| cae1c78 | Tom Lane | 10 June 2016, 00:16:11 UTC | Improve the situation for parallel query versus temp relations. Transmit the leader's temp-namespace state to workers. This is important because without it, the workers do not really have the same search path as the leader. For example, there is no good reason (and no extant code either) to prevent a worker from executing a temp function that the leader created previously; but as things stood it would fail to find the temp function, and then either fail or execute the wrong function entirely. We still prohibit a worker from creating a temp namespace on its own. In effect, a worker can only see the session's temp namespace if the leader had created it before starting the worker, which seems like the right semantics. Also, transmit the leader's BackendId to workers, and arrange for workers to use that when determining the physical file path of a temp relation belonging to their session. While the original intent was to prevent such accesses entirely, there were a number of holes in that, notably in places like dbsize.c which assume they can safely access temp rels of other sessions anyway. We might as well get this right, as a small down payment on someday allowing workers to access the leader's temp tables. (With this change, directly using "MyBackendId" as a relation or buffer backend ID is deprecated; you should use BackendIdForTempRelations() instead. I left a couple of such uses alone though, as they're not going to be reachable in parallel workers until we do something about localbuf.c.) Move the thou-shalt-not-access-thy-leader's-temp-tables prohibition down into localbuf.c, which is where it actually matters, instead of having it in relation_open(). This amounts to recognizing that access to temp tables' catalog entries is perfectly safe in a worker, it's only the data in local buffers that is problematic. Having done all that, we can get rid of the test in has_parallel_hazard() that says that use of a temp table's rowtype is unsafe in parallel workers. That test was unduly expensive, and if we really did need such a prohibition, that was not even close to being a bulletproof guard for it. (For example, any user-defined function executed in a parallel worker might have attempted such access.) | 10 June 2016, 00:16:11 UTC |
| 2410a25 | Robert Haas | 09 June 2016, 22:09:17 UTC | Repair a bit of pgindent damage. Inserting line-breaks into the middle of a URL is, to put it mildly, not very helpful, so persuade pgindent to leave it alone. | 09 June 2016, 22:09:17 UTC |
| 4bc424b | Robert Haas | 09 June 2016, 22:02:36 UTC | pgindent run for 9.6 | 09 June 2016, 22:02:36 UTC |
| 9164dee | Robert Haas | 09 June 2016, 21:18:20 UTC | Update pgrowlocks extension for parallel query. The pgrowlocks function provided by this extension is PARALLEL SAFE. Andreas Karlsson | 09 June 2016, 21:35:53 UTC |
