{"push_id":2625638969,"size":663,"distinct_size":663,"ref":"refs/heads/master","head":"a23aa4f7241c18c92746c4a7f2aa8c864a7dea99","before":"5748f3a0aa7cf78ac6979010273bd9d50869bb8e","commits":[{"sha":"b6e132ddc8601c99ac5466792f6128ee859f4128","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"In psql, restore old behavior of Query_for_list_of_functions.\n\nHistorically, tab completion for functions has offered the names of\naggregates as well.  This is essential in at least one context, namely\nGRANT/REVOKE, because there is no GRANT ON AGGREGATE syntax.  There\nare other cases where a command that nominally is for functions will\nallow aggregates as well, though not all do.\n\nCommit fd1a421fe changed this query to disallow aggregates, but that\ndoesn't seem to have been thought through very carefully.  Change it\nto allow aggregates (but still ignore procedures).\n\nWe might at some point tighten this up, but it'd require sorting through\nall the uses of this query to see which ones should offer aggregate\nnames and which shouldn't.  Given the lack of field complaints about\nthe historical laxity here, that's work I'm not eager to do right now.\n\nDiscussion: https://postgr.es/m/14268.1520283126@sss.pgh.pa.us","distinct":true,"url":"https://api.github.com/repos/eubide/postgres/commits/b6e132ddc8601c99ac5466792f6128ee859f4128"},{"sha":"fedabe1f64467b777b1d5ef53b5b0015acc7b999","author":{"name":"Magnus Hagander","email":"9f4ca770b638615ac5c3e0d2da16b77c80c2f2c6@hagander.net"},"message":"Clarify initdb --help message for --wal-segsize\n\nSpecify that the value is in megabytes. This aligns the message with\nwhat's in the documentation.","distinct":true,"url":"https://api.github.com/repos/eubide/postgres/commits/fedabe1f64467b777b1d5ef53b5b0015acc7b999"},{"sha":"4a4e2442a7f7c1434e86dd290cdb3704cfebb24c","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Fix improper uses of canonicalize_qual().\n\nOne of the things canonicalize_qual() does is to remove constant-NULL\nsubexpressions of top-level AND/OR clauses.  It does that on the assumption\nthat what it's given is a top-level WHERE clause, so that NULL can be\ntreated like FALSE.  Although this is documented down inside a subroutine\nof canonicalize_qual(), it wasn't mentioned in the documentation of that\nfunction itself, and some callers hadn't gotten that memo.\n\nNotably, commit d007a9505 caused get_relation_constraints() to apply\ncanonicalize_qual() to CHECK constraints.  That allowed constraint\nexclusion to misoptimize situations in which a CHECK constraint had a\nprovably-NULL subclause, as seen in the regression test case added here,\nin which a child table that should be scanned is not.  (Although this\nthinko is ancient, the test case doesn't fail before 9.2, for reasons\nI've not bothered to track down in detail.  There may be related cases\nthat do fail before that.)\n\nMore recently, commit f0e44751d added an independent bug by applying\ncanonicalize_qual() to index expressions, which is even sillier since\nthose might not even be boolean.  If they are, though, I think this\ncould lead to making incorrect index entries for affected index\nexpressions in v10.  I haven't attempted to prove that though.\n\nTo fix, add an \"is_check\" parameter to canonicalize_qual() to specify\nwhether it should assume WHERE or CHECK semantics, and make it perform\nNULL-elimination accordingly.  Adjust the callers to apply the right\nsemantics, or remove the call entirely in cases where it's not known\nthat the expression has one or the other semantics.  I also removed\nthe call in some cases involving partition expressions, where it should\nbe a no-op because such expressions should be canonical already ...\nand was a no-op, independently of whether it could in principle have\ndone something, because it was being handed the qual in implicit-AND\nformat which isn't what it expects.  In HEAD, add an Assert to catch\nthat type of mistake in future.\n\nThis represents an API break for external callers of canonicalize_qual().\nWhile that's intentional in HEAD to make such callers think about which\ncase applies to them, it seems like something we probably wouldn't be\nthanked for in released branches.  Hence, in released branches, the\nextra parameter is added to a new function canonicalize_qual_ext(),\nand canonicalize_qual() is a wrapper that retains its old behavior.\n\nPatch by me with suggestions from Dean Rasheed.  Back-patch to all\nsupported branches.\n\nDiscussion: https://postgr.es/m/24475.1520635069@sss.pgh.pa.us","distinct":true,"url":"https://api.github.com/repos/eubide/postgres/commits/4a4e2442a7f7c1434e86dd290cdb3704cfebb24c"},{"sha":"c4af6960e3d82968c51995937c12bd4885183caa","author":{"name":"Alvaro Herrera","email":"3c84f0de6f8a0f296d36cdd9f57fa166641c96b1@alvh.no-ip.org"},"message":"Remove doc sentence no longer applicable\n\nAmit Langote","distinct":true,"url":"https://api.github.com/repos/eubide/postgres/commits/c4af6960e3d82968c51995937c12bd4885183caa"},{"sha":"3beb46ae8118f64d94518ba105b5e5c79e2ce194","author":{"name":"Alvaro Herrera","email":"3c84f0de6f8a0f296d36cdd9f57fa166641c96b1@alvh.no-ip.org"},"message":"docs: Fix typo: a -> an\n\nDavid Rowley","distinct":true,"url":"https://api.github.com/repos/eubide/postgres/commits/3beb46ae8118f64d94518ba105b5e5c79e2ce194"},{"sha":"63cbee6a786028790abc6ae9b9606366bae5e01d","author":{"name":"Alvaro Herrera","email":"3c84f0de6f8a0f296d36cdd9f57fa166641c96b1@alvh.no-ip.org"},"message":"doc: Reword restriction on partition keys in unique indexes\n\nNew wording from David G. Johnston, who noticed the unreadable original\nalso.  Include his suggested test case as well.\n\nFix a typo I noticed elsewhere while doing this.\n\nDiscussion: https://postgr.es/m/CAKFQuwY4Ld7ecxL_KAmaxwt0FUu5VcPPN2L4dh+3BeYbrdBa5g@mail.gmail.com","distinct":true,"url":"https://api.github.com/repos/eubide/postgres/commits/63cbee6a786028790abc6ae9b9606366bae5e01d"},{"sha":"1f8a3327a9db9a8a662fb39fdcde2337acffa68c","author":{"name":"Alvaro Herrera","email":"3c84f0de6f8a0f296d36cdd9f57fa166641c96b1@alvh.no-ip.org"},"message":"Avoid having two PKs in a partition\n\nIf a table containing a primary key is attach as partition to a\npartitioned table which has a primary key with a different definition,\nwe would happily create a second one in the new partition.  Oops.  It\nturns out that this is because an error check in DefineIndex is executed\nonly if you tell it that it's being run by ALTER TABLE, and the original\ncode here wasn't.  Change it so that it does.\n\nAdded a couple of test cases for this, also.  A previously working test\nstarted to fail in a different way than before patch because the new\ncheck is called earlier; change the PK to plain UNIQUE so that the new\nbehavior isn't invoked, so that the test continues to verify what we\nwant it to verify.\n\nReported by: Noriyoshi Shinoda\nDiscussion: https://postgr.es/m/DF4PR8401MB102060EC2615EC9227CC73F7EEDF0@DF4PR8401MB1020.NAMPRD84.PROD.OUTLOOK.COM","distinct":true,"url":"https://api.github.com/repos/eubide/postgres/commits/1f8a3327a9db9a8a662fb39fdcde2337acffa68c"},{"sha":"377b5ac4845c5ffbf992ee95c32d7d16d38b9081","author":{"name":"Peter Eisentraut","email":"c50e6bf7013fce877ffb25104d778a36de31e297@gmx.net"},"message":"Fix CREATE TABLE / LIKE with bigint identity column\n\nCREATE TABLE / LIKE with a bigint identity column would fail on\nplatforms where long is 32 bits.  Copying the sequence values used\nmakeInteger(), which would truncate the 64-bit sequence data to 32 bits.\nTo fix, use makeFloat() instead, like the parser.  (This does not\nactually make use of floats, but stores the values as strings.)\n\nBug: #15096\nReviewed-by: Michael Paquier <michael@paquier.xyz>","distinct":true,"url":"https://api.github.com/repos/eubide/postgres/commits/377b5ac4845c5ffbf992ee95c32d7d16d38b9081"},{"sha":"6cf86f435472b27bbc5e22c713bca08aa2d94af7","author":{"name":"Peter Eisentraut","email":"c50e6bf7013fce877ffb25104d778a36de31e297@gmx.net"},"message":"Change internal integer representation of Value node\n\nA Value node would store an integer as a long.  This causes needless\nportability risks, as long can be of varying sizes.  Change it to use\nint instead.  All code using this was already careful to only store\n32-bit values anyway.\n\nReviewed-by: Michael Paquier <michael@paquier.xyz>","distinct":true,"url":"https://api.github.com/repos/eubide/postgres/commits/6cf86f435472b27bbc5e22c713bca08aa2d94af7"},{"sha":"17bb62501787c56e0518e61db13a523d47afd724","author":{"name":"Peter Eisentraut","email":"c50e6bf7013fce877ffb25104d778a36de31e297@gmx.net"},"message":"Move strtoint() to common\n\nSeveral places used similar code to convert a string to an int, so take\nthe function that we already had and make it globally available.\n\nReviewed-by: Michael Paquier <michael@paquier.xyz>","distinct":true,"url":"https://api.github.com/repos/eubide/postgres/commits/17bb62501787c56e0518e61db13a523d47afd724"},{"sha":"b32fad52e94307261471d05a79c70f8382d71657","author":{"name":"Michael Meskes","email":"194ab8dd455e11882084133e0b9c41a286f6e7bc@postgresql.org"},"message":"Set connection back to NULL after freeing it.\n\nPatch by Jeevan Ladhe <jeevan.ladhe@enterprisedb.com>","distinct":true,"url":"https://api.github.com/repos/eubide/postgres/commits/b32fad52e94307261471d05a79c70f8382d71657"},{"sha":"38f7831d703be98aaece8af6625faeab5123a02c","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Avoid holding AutovacuumScheduleLock while rechecking table statistics.\n\nIn databases with many tables, re-fetching the statistics takes some time,\nso that this behavior seriously decreases the available concurrency for\nmultiple autovac workers.  There's discussion afoot about more complete\nfixes, but a simple and back-patchable amelioration is to claim the table\nand release the lock before rechecking stats.  If we find out there's no\nlonger a reason to process the table, re-taking the lock to un-claim the\ntable is cheap enough.\n\n(This patch is quite old, but got lost amongst a discussion of more\naggressive fixes.  It's not clear when or if such a fix will be\naccepted, but in any case it'd be unlikely to get back-patched.\nLet's do this now so we have some improvement for the back branches.)\n\nIn passing, make the normal un-claim step take AutovacuumScheduleLock\nnot AutovacuumLock, since that is what is documented to protect the\nwi_tableoid field.  This wasn't an actual bug in view of the fact that\nreaders of that field hold both locks, but it creates some concurrency\npenalty against operations that need only AutovacuumLock.\n\nBack-patch to all supported versions.\n\nJeff Janes\n\nDiscussion: https://postgr.es/m/26118.1520865816@sss.pgh.pa.us","distinct":true,"url":"https://api.github.com/repos/eubide/postgres/commits/38f7831d703be98aaece8af6625faeab5123a02c"},{"sha":"d04900de7d0cb5b6ecb6d5bf9fdb6f3105824f81","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"When updating reltuples after ANALYZE, just extrapolate from our sample.\n\nThe existing logic for updating pg_class.reltuples trusted the sampling\nresults only for the pages ANALYZE actually visited, preferring to\nbelieve the previous tuple density estimate for all the unvisited pages.\nWhile there's some rationale for doing that for VACUUM (first that\nVACUUM is likely to visit a very nonrandom subset of pages, and second\nthat we know for sure that the unvisited pages did not change), there's\nno such rationale for ANALYZE: by assumption, it's looked at an unbiased\nrandom sample of the table's pages.  Furthermore, in a very large table\nANALYZE will have examined only a tiny fraction of the table's pages,\nmeaning it cannot slew the overall density estimate very far at all.\nIn a table that is physically growing, this causes reltuples to increase\nnearly proportionally to the change in relpages, regardless of what is\nactually happening in the table.  This has been observed to cause reltuples\nto become so much larger than reality that it effectively shuts off\nautovacuum, whose threshold for doing anything is a fraction of reltuples.\n(Getting to the point where that would happen seems to require some\nadditional, not well understood, conditions.  But it's undeniable that if\nreltuples is seriously off in a large table, ANALYZE alone will not fix it\nin any reasonable number of iterations, especially not if the table is\ncontinuing to grow.)\n\nHence, restrict the use of vac_estimate_reltuples() to VACUUM alone,\nand in ANALYZE, just extrapolate from the sample pages on the assumption\nthat they provide an accurate model of the whole table.  If, by very bad\nluck, they don't, at least another ANALYZE will fix it; in the old logic\na single bad estimate could cause problems indefinitely.\n\nIn HEAD, let's remove vac_estimate_reltuples' is_analyze argument\naltogether; it was never used for anything and now it's totally pointless.\nBut keep it in the back branches, in case any third-party code is calling\nthis function.\n\nPer bug #15005.  Back-patch to all supported branches.\n\nDavid Gould, reviewed by Alexander Kuzmenkov, cosmetic changes by me\n\nDiscussion: https://postgr.es/m/20180117164916.3fdcf2e9@engels","distinct":true,"url":"https://api.github.com/repos/eubide/postgres/commits/d04900de7d0cb5b6ecb6d5bf9fdb6f3105824f81"},{"sha":"0927d2f46ddd4cf7d6bf2cc84b3be923e0aedc52","author":{"name":"Robert Haas","email":"cc4ab156f0be9feefe10b35a552fd319cd7679ae@postgresql.org"},"message":"Let Parallel Append over simple UNION ALL have partial subpaths.\n\nA simple UNION ALL gets flattened into an appendrel of subquery\nRTEs, but up until now it's been impossible for the appendrel to use\nthe partial paths for the subqueries, so we can implement the\nappendrel as a Parallel Append but only one with non-partial paths\nas children.\n\nThere are three separate obstacles to removing that limitation.\nFirst, when planning a subquery, propagate any partial paths to the\nfinal_rel so that they are potentially visible to outer query levels\n(but not if they have initPlans attached, because that wouldn't be\nsafe).  Second, after planning a subquery, propagate any partial paths\nfor the final_rel to the subquery RTE in the outer query level in the\nsame way we do for non-partial paths.  Third, teach finalize_plan() to\naccount for the possibility that the fake parameter we use for rescan\nsignalling when the plan contains a Gather (Merge) node may be\npropagated from an outer query level.\n\nPatch by me, reviewed and tested by Amit Khandekar, Rajkumar\nRaghuwanshi, and Ashutosh Bapat.  Test cases based on examples by\nRajkumar Raghuwanshi.\n\nDiscussion: http://postgr.es/m/CA+Tgmoa6L9A1nNCk3aTDVZLZ4KkHDn1+tm7mFyFvP+uQPS7bAg@mail.gmail.com","distinct":true,"url":"https://api.github.com/repos/eubide/postgres/commits/0927d2f46ddd4cf7d6bf2cc84b3be923e0aedc52"},{"sha":"4f63e85eb149792492a703f01a3a5b89bf5509a7","author":{"name":"Andres Freund","email":"883768b6dd2c42aea0031b24be8a2da40fef4b64@anarazel.de"},"message":"Add COSTS off to two EXPLAIN using tests.\n\nDiscussion: https://postgr.es/m/20180312222023.i4sgkbl4oqtstus3@alap3.anarazel.de","distinct":true,"url":"https://api.github.com/repos/eubide/postgres/commits/4f63e85eb149792492a703f01a3a5b89bf5509a7"},{"sha":"1e22166e5ebbc3df7684209657ea58ba880546d6","author":{"name":"Andres Freund","email":"883768b6dd2c42aea0031b24be8a2da40fef4b64@anarazel.de"},"message":"Expand AND/OR regression tests around NULL handling.\n\nPreviously there were no tests verifying that NULL handling in AND/OR\nwas correct (i.e. that NULL rather than false is returned if\nexpression doesn't return true).\n\nAuthor: Andres Freund","distinct":true,"url":"https://api.github.com/repos/eubide/postgres/commits/1e22166e5ebbc3df7684209657ea58ba880546d6"},{"sha":"db2fc801f66a70969cbdd5673ed9d02025c70695","author":{"name":"Michael Meskes","email":"194ab8dd455e11882084133e0b9c41a286f6e7bc@postgresql.org"},"message":"Fix double frees in ecpg.\n\nPatch by Patrick Krecker <patrick@judicata.com>","distinct":true,"url":"https://api.github.com/repos/eubide/postgres/commits/db2fc801f66a70969cbdd5673ed9d02025c70695"},{"sha":"3b7ab4380440d7b14ee390fabf39f6d87d7491e2","author":{"name":"Michael Meskes","email":"194ab8dd455e11882084133e0b9c41a286f6e7bc@postgresql.org"},"message":"Add Oracle like handling of char arrays.\n\nIn some cases Oracle Pro*C handles char array differently than ECPG. This patch\nadds a Oracle compatibility mode to make ECPG behave like Pro*C.\n\nPatch by David Rader <davidr@openscg.com>","distinct":true,"url":"https://api.github.com/repos/eubide/postgres/commits/3b7ab4380440d7b14ee390fabf39f6d87d7491e2"},{"sha":"df411e7c664ee9a2395eb8c7a74ceddea818d489","author":{"name":"Peter Eisentraut","email":"c50e6bf7013fce877ffb25104d778a36de31e297@gmx.net"},"message":"Add tests for reinit.c\n\nThis tests how the different forks of unlogged tables behave in crash\nrecovery.\n\nAuthor: David Steele <david@pgmasters.net>","distinct":true,"url":"https://api.github.com/repos/eubide/postgres/commits/df411e7c664ee9a2395eb8c7a74ceddea818d489"},{"sha":"97d18ce27da47de2de60de8dfca8e364e71ff6fe","author":{"name":"Stephen Frost","email":"d3eaa418a359156a10c6383b2e3a44959960ecf6@snowman.net"},"message":"Fix comment for ExecProcessReturning\n\nresultRelInfo is the argument for the function, not projectReturning.\n\nAuthor: Etsuro Fujita\nDiscussion: https://postgr.es/m/5AA8E11E.1040609@lab.ntt.co.jp","distinct":true,"url":"https://api.github.com/repos/eubide/postgres/commits/97d18ce27da47de2de60de8dfca8e364e71ff6fe"}]}
{"actor":{"display_login":"eubide"}}