{"push_id":2416107315,"size":8,"distinct_size":1,"ref":"refs/heads/commitfest/17/1482","head":"ef9df61cb2e69e0053000060c55a3db7d189b205","before":"fff173d228f59d82667fb39a7f4bfe145bba184f","commits":[{"sha":"6666ee49f49c4a6b008591aea457becffa0df041","author":{"name":"Alvaro Herrera","email":"7cf34a26c111482b1b00703daedc3ff840f1e2cf@alvh.no-ip.org"},"message":"Fix state reversal after partition tuple routing\n\nWe make some changes to ModifyTableState and the EState it uses whenever\nwe route tuples to partitions; but we weren't restoring properly in all\ncases, possibly causing crashes when partitions with different tuple\ndescriptors are targeted by tuples inserted in the same command.\nRefactor some code, creating ExecPrepareTupleRouting, to encapsulate the\nneeded state changing logic, and have it invoked one level above its\ncurrent place (ie. put it in ExecModifyTable instead of ExecInsert);\nthis makes it all more readable.\n\nAdd a test case to exercise this.\n\nWe don't support having views as partitions; and since only views can\nhave INSTEAD OF triggers, there is no point in testing for INSTEAD OF\nwhen processing insertions into a partitioned table.  Remove code that\nappears to support this (but which is actually never relevant.)\n\nIn passing, fix location of some very confusing comments in\nModifyTableState.\n\nReported-by: Amit Langote\nAuthor: Etsuro Fujita, Amit Langote\nDiscussion: https://postgr/es/m/0473bf5c-57b1-f1f7-3d58-455c2230bc5f@lab.ntt.co.jp","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/6666ee49f49c4a6b008591aea457becffa0df041"},{"sha":"839a8eb2b3df68e105fb4f7a72e71652d6becc7a","author":{"name":"Alvaro Herrera","email":"7cf34a26c111482b1b00703daedc3ff840f1e2cf@alvh.no-ip.org"},"message":"Expand comment a little bit\n\nThe previous commit removed a comment that was a bit more verbose than\nits replacement.","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/839a8eb2b3df68e105fb4f7a72e71652d6becc7a"},{"sha":"ee0a1fc84eb29c916687dc5bd26909401d3aa8cd","author":{"name":"Alvaro Herrera","email":"7cf34a26c111482b1b00703daedc3ff840f1e2cf@alvh.no-ip.org"},"message":"Remove unnecessary members from ModifyTableState and ExecInsert\n\nThese values can be obtained from the ModifyTable node which is already\na part of both the ModifyTableState and ExecInsert.\n\nAuthor: Álvaro Herrera, Amit Langote\nReviewed-by: Peter Geoghegan\nDiscussion: https://postgr.es/m/20180316151303.rml2p5wffn3o6qy6@alvherre.pgsql","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/ee0a1fc84eb29c916687dc5bd26909401d3aa8cd"},{"sha":"6fbd5cce22ebd2203d99cd7dcd179d0e1138599e","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Fix performance hazard in REFRESH MATERIALIZED VIEW CONCURRENTLY.\n\nJeff Janes discovered that commit 7ca25b7de made one of the queries run by\nREFRESH MATERIALIZED VIEW CONCURRENTLY perform badly.  The root cause is\nbad cardinality estimation for correlated quals, but a principled solution\nto that problem is some way off, especially since the planner lacks any\nstatistics about whole-row variables.  Moreover, in non-error cases this\nquery produces no rows, meaning it must be run to completion; but use of\nLIMIT 1 encourages the planner to pick a fast-start, slow-completion plan,\nexactly not what we want.  Remove the LIMIT clause, and instead rely on\nthe count parameter we pass to SPI_execute() to prevent excess work if the\nquery does return some rows.\n\nWhile we've heard no field reports of planner misbehavior with this query,\nit could be that people are having performance issues that haven't reached\nthe level of pain needed to cause a bug report.  In any case, that LIMIT\nclause can't possibly do anything helpful with any existing version of the\nplanner, and it demonstrably can cause bad choices in some cases, so\nback-patch to 9.4 where the code was introduced.\n\nThomas Munro\n\nDiscussion: https://postgr.es/m/CAMkU=1z-JoGymHneGHar1cru4F1XDfHqJDzxP_CtK5cL3DOfmg@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/6fbd5cce22ebd2203d99cd7dcd179d0e1138599e"},{"sha":"9ad21a6957ff2d8743e9a59ba062d3c009b24ec4","author":{"name":"Andrew Dunstan","email":"6b7c097d961f68685fc978cf91eeae17be6cbb45@dunslane.net"},"message":"Don't use an Msys virtual path to create a tablespace\n\nThe new unlogged_reinit recovery tests create a new tablespace using\nTestLib.pm's tempdir. However, on msys that function returns a virtual\npath that isn't understood by Postgres. Here we add a new function to\nTestLib.pm to turn such a path into a real path on the underlying file\nsystem, and use it in the new test to create the tablespace. The new\nfunction is essentially a NOOP everywhere but msys.","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/9ad21a6957ff2d8743e9a59ba062d3c009b24ec4"},{"sha":"6497a18e6c1b5874566a77737ec3d381fded3ec2","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Fix some corner-case issues in REFRESH MATERIALIZED VIEW CONCURRENTLY.\n\nrefresh_by_match_merge() has some issues in the way it builds a SQL\nquery to construct the \"diff\" table:\n\n1. It doesn't require the selected unique index(es) to be indimmediate.\n2. It doesn't pay attention to the particular equality semantics enforced\nby a given index, but just assumes that they must be those of the column\ndatatype's default btree opclass.\n3. It doesn't check that the indexes are btrees.\n4. It's insufficiently careful to ensure that the parser will pick the\nintended operator when parsing the query.  (This would have been a\nsecurity bug before CVE-2018-1058.)\n5. It's not careful about indexes on system columns.\n\nThe way to fix #4 is to make use of the existing code in ri_triggers.c\nfor generating an arbitrary binary operator clause.  I chose to move\nthat to ruleutils.c, since that seems a more reasonable place to be\nexporting such functionality from than ri_triggers.c.\n\nWhile #1, #3, and #5 are just latent given existing feature restrictions,\nand #2 doesn't arise in the core system for lack of alternate opclasses\nwith different equality behaviors, #4 seems like an issue worth\nback-patching.  That's the bulk of the change anyway, so just back-patch\nthe whole thing to 9.4 where this code was introduced.\n\nDiscussion: https://postgr.es/m/13836.1521413227@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/6497a18e6c1b5874566a77737ec3d381fded3ec2"},{"sha":"13c7c65ec900a30bcddcb27f5fd138dcdbc2ca2e","author":{"name":"Peter Eisentraut","email":"2f47089682e4afbd5de3eea4edffc95dfc1eb9de@gmx.net"},"message":"Add missing break","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/13c7c65ec900a30bcddcb27f5fd138dcdbc2ca2e"},{"sha":"ef9df61cb2e69e0053000060c55a3db7d189b205","author":{"name":"Commitfest Bot","email":"aab6a594935fe5db0d690bc154b19f642bfbe9d7@cputube.org"},"message":"[CF 17/1482] pg_rewind corrupts control file global/pg_control\n\nThis commit was automatically generated by cfbot at commitfest.cputube.org.\nIt is based on patches submitted to the PostgreSQL mailing lists and\nregistered in the PostgreSQL Commitfest application.\n\nThis branch will be overwritten each time a new patch version is posted to\nthe email thread or the master branch changes.\n\nCommitfest entry: https://commitfest.postgresql.org/17/1482\nPatch(es): https://www.postgresql.org/message-id/20180305075431.GH2266%40paquier.xyz\nAuthor(s): Michael Paquier","distinct":true,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/ef9df61cb2e69e0053000060c55a3db7d189b205"}]}
{"actor":{"display_login":"postgresql-cfbot"}}