{"push_id":2349444566,"size":3,"distinct_size":1,"ref":"refs/heads/commitfest/17/1465","head":"a181d42766e82776125c4a9f5cdfe372778d6b79","before":"5e4706dc4cda37eb23e9dfa89b7aaf2e535b016e","commits":[{"sha":"38b41f182a66b67e36e2adf53d078599b1b65483","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Repair pg_upgrade's failure to preserve relfrozenxid for matviews.\n\nThis oversight led to data corruption in matviews, manifesting as\n\"could not access status of transaction\" before our most recent releases,\nand \"found xmin from before relfrozenxid\" errors since then.\n\nThe proximate cause of the problem seems to have been confusion between\nthe task of preserving dropped-column status and the task of preserving\nfrozenxid status.  Those are required for distinct sets of relkinds,\nand the reasoning was entirely undocumented in the source code.  In hopes\nof forestalling future errors of the same kind, try to improve the\ncommentary in this area.\n\nIn passing, also improve the remarkably unhelpful comments around\npg_upgrade's set_frozenxids().  That's not actually buggy AFAICS,\nbut good luck figuring out what it does from the old comments.\n\nPer report from Claudio Freire.  It appears that bug #14852 from Alexey\nErmakov is an earlier report of the same issue, and there may be other\ncases that we failed to identify at the time.\n\nPatch by me based on analysis by Andres Freund.  The bug dates back\nto the introduction of matviews, so back-patch to all supported branches.\n\nDiscussion: https://postgr.es/m/CAGTBQpbrY9CdRGGhyBZ9yqY4jWaGC85rUF4X+R7d-aim=mBNsw@mail.gmail.com\nDiscussion: https://postgr.es/m/20171013115320.28049.86457@wrigleys.postgresql.org","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/38b41f182a66b67e36e2adf53d078599b1b65483"},{"sha":"7d8ac9814bc9bb6df2d845dbabed38d7284c7c2c","author":{"name":"Robert Haas","email":"93159bdbbeed5b47be970d58edfbdf1c3ce55e4c@postgresql.org"},"message":"Charge cpu_tuple_cost * 0.5 for Append and MergeAppend nodes.\n\nPreviously, Append didn't charge anything at all, and MergeAppend\ncharged only cpu_operator_cost, about half the value used here.  This\nchange might make MergeAppend plans slightly more likely to be chosen\nthan before, since this commit increases the assumed cost for Append\n-- with default values -- by 0.005 per tuple but MergeAppend by only\n0.0025 per tuple.  Since the comparisons required by MergeAppend are\ncosted separately, it's not clear why MergeAppend needs to be\notherwise more expensive than Append, so hopefully this is OK.\n\nPrior to partition-wise join, it didn't really matter whether or not\nan Append node had any cost of its own, because every plan had to use\nthe same number of Append or MergeAppend nodes and in the same places.\nOnly the relative cost of Append vs. MergeAppend made a difference.\nNow, however, it is possible to avoid some of the Append nodes using a\npartition-wise join, so it's worth making an effort.  Pending patches\nfor partition-wise aggregate care too, because an Append of Aggregate\nnodes will incur the Append overhead fewer times than an Aggregate\nover an Append.  Although in most cases this change will favor the use\nof partition-wise techniques, it does the opposite when the join\ncardinality is greater than the sum of the input cardinalities.  Since\nthis situation arises in an existing regression test, I [rhaas]\nadjusted it to keep the overall plan shape approximately the same.\n\nJeevan Chalke, per a suggestion from David Rowley.  Reviewed by\nAshutosh Bapat.  Some changes by me.  The larger patch series of which\nthis patch is a part was also reviewed and tested by Antonin Houska,\nRajkumar Raghuwanshi, David Rowley, Dilip Kumar, Konstantin Knizhnik,\nPascal Legrand, Rafia Sabih, and me.\n\nDiscussion: http://postgr.es/m/CAKJS1f9UXdk6ZYyqbJnjFO9a9hyHKGW7B=ZRh-rxy9qxfPA5Gw@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/7d8ac9814bc9bb6df2d845dbabed38d7284c7c2c"},{"sha":"a181d42766e82776125c4a9f5cdfe372778d6b79","author":{"name":"Commitfest Bot","email":"aab6a594935fe5db0d690bc154b19f642bfbe9d7@cputube.org"},"message":"[CF 17/1465] pgbench - add ability to control random seed\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/1465\nPatch(es): https://www.postgresql.org/message-id/alpine.DEB.2.20.1801241031460.2307%40lancre\nAuthor(s): Fabien Coelho","distinct":true,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/a181d42766e82776125c4a9f5cdfe372778d6b79"}]}
{"actor":{"display_login":"postgresql-cfbot"}}