{"push_id":3044057471,"size":12,"distinct_size":1,"ref":"refs/heads/commitfest/20/1838","head":"e8d1219fc92c0f20017c6d44b1a70784f1b053fd","before":"0cfeda82453841d31916c4672f8d1eb5fa1975be","commits":[{"sha":"253b3f6760e850945a91e2d872eab3b2802ffca2","author":{"name":"Peter Eisentraut","email":"c50e6bf7013fce877ffb25104d778a36de31e297@gmx.net"},"message":"doc: Small run-time pruning doc fix\n\nA note in ddl.sgml used to mention that run-time pruning was only\nimplemented for Append.  When we got MergeAppend support, this was\nupdated to mention that MergeAppend is supported too.  This is\nslightly weird as it's not all that obvious what exactly isn't\nsupported when we mention:\n\n    <para>\n     Both of these behaviors are likely to be changed in a future release\n     of <productname>PostgreSQL</productname>.\n    </para>\n\nThis patch updates this to mention that ModifyTable is unsupported,\nwhich makes the above fragment make sense again.\n\nAuthor: David Rowley <david.rowley@2ndquadrant.com>","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/253b3f6760e850945a91e2d872eab3b2802ffca2"},{"sha":"fc151211ef1f99934b8789591241525adfdee9d6","author":{"name":"Peter Eisentraut","email":"c50e6bf7013fce877ffb25104d778a36de31e297@gmx.net"},"message":"doc: Small punctuation improvement","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/fc151211ef1f99934b8789591241525adfdee9d6"},{"sha":"ffb68980e3c9dc453812c70449ff2d36d5a7f6af","author":{"name":"Michael Paquier","email":"17b9e1c64588c7fa6419b4d29dc1f4426279ba01@paquier.xyz"},"message":"Fix incorrect author name in release notes\n\nAuthor: Alexander Lakhin\nDiscussion: https://postgr.es/m/2f55f6d2-3fb0-d4f6-5c47-18da3a1117e0@gmail.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/ffb68980e3c9dc453812c70449ff2d36d5a7f6af"},{"sha":"e3f005d974ce32ca9f74328067efafcb1217c87f","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Limit the number of index clauses considered in choose_bitmap_and().\n\nclassify_index_clause_usage() is O(N^2) in the number of distinct index\nqual clauses it considers, because of its use of a simple search list to\nstore them.  For nearly all queries, that's fine because only a few clauses\nwill be considered.  But Alexander Kuzmenkov reported a machine-generated\nquery with 80000 (!) index qual clauses, which caused this code to take\nforever.  Somewhat remarkably, this is the only O(N^2) behavior we now\nhave for such a query, so let's fix it.\n\nWe can get rid of the O(N^2) runtime for cases like this without much\ndamage to the functionality of choose_bitmap_and() by separating out\npaths with \"too many\" qual or pred clauses, and deeming them to always\nbe nonredundant with other paths.  Then their clauses needn't go into\nthe search list, so it doesn't get too long, but we don't lose the\nability to consider bitmap AND plans altogether.  I set the threshold\nfor \"too many\" to be 100 clauses per path, which should be plenty to\nensure no change in planning behavior for normal queries.\n\nThere are other things we could do to make this go faster, but it's not\nclear that it's worth any additional effort.  80000 qual clauses require\na whole lot of work in many other places, too.\n\nThe code's been like this for a long time, so back-patch to all supported\nbranches.  The troublesome query only works back to 9.5 (in 9.4 it fails\nwith stack overflow in the parser); so I'm not sure that fixing this in\n9.4 has any real-world benefit, but perhaps it does.\n\nDiscussion: https://postgr.es/m/90c5bdfa-d633-dabe-9889-3cf3e1acd443@postgrespro.ru","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/e3f005d974ce32ca9f74328067efafcb1217c87f"},{"sha":"3de491482b6c815a2e735dbbb8972e0907d75188","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Simplify null-element handling in extension_config_remove().\n\nThere's no point in asking deconstruct_array() for a null-flags\narray when we already checked the array has no nulls, and aren't\ngoing to examine the output anyhow.  Not asking for this output\nshould make the code marginally faster, and it's also more\nrobust since if there somehow were nulls, deconstruct_array()\nwould throw an error.\n\nDaniel Gustafsson\n\nDiscussion: https://postgr.es/m/289FFB8B-7AAB-48B5-A497-6E0D41D7BA47@yesql.se","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/3de491482b6c815a2e735dbbb8972e0907d75188"},{"sha":"52b70b1c7df5929465cf3dd8f4798e6f2e204f61","author":{"name":"Michael Paquier","email":"17b9e1c64588c7fa6419b4d29dc1f4426279ba01@paquier.xyz"},"message":"Remove CommandCounterIncrement() after processing ON COMMIT DELETE\n\nThis comes from f9b5b41, which is part of one the original commits that\nimplemented ON COMMIT actions.  By looking at the truncation code, any\nCCI needed happens locally when rebuilding indexes, so it looks safe to\njust remove this final incrementation.\n\nAuthor: Michael Paquier\nReviewed-by: Álvaro Herrera\nDiscussion: https://postgr.es/m/20181109024731.GF2652@paquier.xyz","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/52b70b1c7df5929465cf3dd8f4798e6f2e204f61"},{"sha":"6a3dcd28568a04b6e4aea2bf41ea2c7e9c7b0e96","author":{"name":"Thomas Munro","email":"1ff054ef0838bf068a4b7c40eef026e560a37025@postgresql.org"},"message":"Fix possible buffer overrun in hba.c.\n\nCoverty reports a possible buffer overrun in the code that populates the\npg_hba_file_rules view.  It may not be a live bug due to restrictions\non options that can be used together, but let's increase MAX_HBA_OPTIONS\nand correct a nearby misleading comment.\n\nBack-patch to 10 where this code arrived.\n\nReported-by: Julian Hsiao\nDiscussion: https://postgr.es/m/CADnGQpzbkWdKS2YHNifwAvX5VEsJ5gW49U4o-7UL5pzyTv4vTg%40mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/6a3dcd28568a04b6e4aea2bf41ea2c7e9c7b0e96"},{"sha":"257ef3cd4fec7ca1213f31b660486b492b1c7031","author":{"name":"Thomas Munro","email":"1ff054ef0838bf068a4b7c40eef026e560a37025@postgresql.org"},"message":"Fix handling of HBA ldapserver with multiple hostnames.\n\nCommit 35c0754f failed to handle space-separated lists of alternative\nhostnames in ldapserver, when building a URI for ldap_initialize()\n(OpenLDAP).  Such lists need to be expanded to space-separated URIs.\n\nRepair.  Back-patch to 11, to fix bug report #15495.\n\nAuthor: Thomas Munro\nReported-by: Renaud Navarro\nDiscussion: https://postgr.es/m/15495-2c39fc196c95cd72%40postgresql.org","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/257ef3cd4fec7ca1213f31b660486b492b1c7031"},{"sha":"a53bc135fb07d600869917661d65f45506165c00","author":{"name":"Amit Kapila","email":"4c828daf437d3cc4e3dadceacc8c2924836485c1@postgresql.org"},"message":"Fix the initialization of atomic variables introduced by the\ngroup clearing mechanism.\n\nCommits 0e141c0fbb and baaf272ac9 introduced initialization of atomic\nvariables in InitProcess which means that it's not safe to look at those\nfor backends that aren't currently in use.  Fix that by initializing them\nduring postmaster startup.\n\nReported-by: Andres Freund\nAuthor: Amit Kapila\nBackpatch-through: 9.6\nDiscussion: https://postgr.es/m/20181027104138.qmbbelopvy7cw2qv@alap3.anarazel.de","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/a53bc135fb07d600869917661d65f45506165c00"},{"sha":"b59d4d6c36e14ba4097fa8dac3d31ca86f7f507d","author":{"name":"Thomas Munro","email":"1ff054ef0838bf068a4b7c40eef026e560a37025@postgresql.org"},"message":"Fix const correctness warning.\n\nPer buildfarm.","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/b59d4d6c36e14ba4097fa8dac3d31ca86f7f507d"},{"sha":"6178f3cb798f2ea9011c55e99973f838719c550e","author":{"name":"Peter Eisentraut","email":"c50e6bf7013fce877ffb25104d778a36de31e297@gmx.net"},"message":"pg_dump: Fix dumping of WITH OIDS tables\n\nA table with OIDs that was the first in the dump output would not get\ndumped with OIDs enabled.  Fix that.\n\nThe reason was that the currWithOids flag was declared to be bool but\nactually also takes a -1 value for \"don't know yet\".  But under\nstdbool.h semantics, that is coerced to true, so the required SET\ndefault_with_oids command is not output again.  Change the variable\ntype to char to fix that.\n\nReported-by: Derek Nelson <derek@pipelinedb.com>","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/6178f3cb798f2ea9011c55e99973f838719c550e"},{"sha":"e8d1219fc92c0f20017c6d44b1a70784f1b053fd","author":{"name":"Commitfest Bot","email":"b9e638e07cc2e2abf56c9c0cad7954f2e3bc1641@cputube.org"},"message":"[CF 20/1838] SIGPIPE handling in COPY TO/FROM PROGRAM\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, and also periodically to check for bitrot caused by changes\non the master branch.\n\nCommitfest entry: https://commitfest.postgresql.org/20/1838\nPatch(es): https://www.postgresql.org/message-id/5BEA9E82.1080709@lab.ntt.co.jp\nAuthor(s): Tom Lane","distinct":true,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/e8d1219fc92c0f20017c6d44b1a70784f1b053fd"}]}
{"actor":{"display_login":"postgresql-cfbot"}}