{"push_id":2415689626,"size":8,"distinct_size":1,"ref":"refs/heads/commitfest/17/1138","head":"44767f13af80af54a3f7dd75e4333e44a2cae84e","before":"7ac243f7a28f2967e7485218485b948e1be50037","commits":[{"sha":"49525c46309828b3024fe8040fa99c7dcc83933d","author":{"name":"Robert Haas","email":"93159bdbbeed5b47be970d58edfbdf1c3ce55e4c@postgresql.org"},"message":"Rewrite recurse_union_children to iterate, rather than recurse.\n\nAlso, rename it to plan_union_chidren, so the old name wasn't\nvery descriptive.  This results in a small net reduction in code,\nseems at least to me to be easier to understand, and saves\nspace on the process stack.\n\nPatch by me, reviewed and tested by Ashutosh Bapat and Rajkumar\nRaghuwanshi.\n\nDiscussion: http://postgr.es/m/CA+TgmoaLRAOqHmMZx=ESM3VDEPceg+-XXZsRXQ8GtFJO_zbMSw@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/49525c46309828b3024fe8040fa99c7dcc83933d"},{"sha":"c596fadbfe20ff50a8e5f4bc4b4ff5b7c302ecc0","author":{"name":"Robert Haas","email":"93159bdbbeed5b47be970d58edfbdf1c3ce55e4c@postgresql.org"},"message":"Generate a separate upper relation for each stage of setop planning.\n\nCommit 3fc6e2d7f5b652b417fa6937c34de2438d60fa9f made setop planning\nstages return paths rather than plans, but all such paths were loosely\nassociated with a single RelOptInfo, and only the final path was added\nto the RelOptInfo.  Even at the time, it was foreseen that this should\nbe changed, because there is otherwise no good way for a single stage\nof setop planning to return multiple paths.  With this patch, each\nstage of set operation planning now creates a separate RelOptInfo;\nthese are distinguished by using appropriate relid sets.  Note that\nthis patch does nothing whatsoever about actually returning multiple\npaths for the same set operation; it just makes it possible for a\nfuture patch to do so.\n\nAlong the way, adjust things so that create_upper_paths_hook is called\nfor each of these new RelOptInfos rather than just once, since that\nmight be useful to extensions using that hook.  It might be a good\nto provide an FDW API here as well, but I didn't try to do that for\nnow.\n\nPatch by me, reviewed and tested by Ashutosh Bapat and Rajkumar\nRaghuwanshi.\n\nDiscussion: http://postgr.es/m/CA+TgmoaLRAOqHmMZx=ESM3VDEPceg+-XXZsRXQ8GtFJO_zbMSw@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/c596fadbfe20ff50a8e5f4bc4b4ff5b7c302ecc0"},{"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":"44767f13af80af54a3f7dd75e4333e44a2cae84e","author":{"name":"Commitfest Bot","email":"aab6a594935fe5db0d690bc154b19f642bfbe9d7@cputube.org"},"message":"[CF 17/1138] Improve compactify_tuples and PageRepairFragmentation\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/1138\nPatch(es): https://www.postgresql.org/message-id/9410de56-794b-147f-20f2-d5ef28e98e45%40gmail.com\nAuthor(s): Yura Sokolov","distinct":true,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/44767f13af80af54a3f7dd75e4333e44a2cae84e"}]}
{"actor":{"display_login":"postgresql-cfbot"}}