{"push_id":1041268452,"size":38,"distinct_size":38,"ref":"refs/heads/master","head":"656ee8489053aafc85324b9ef7e91b645674ffb9","before":"7caaeaf3607fae91318f24debce3dc017ca299a3","commits":[{"sha":"d543170f2fdd6d9845aaf91dc0f6be7a2bf0d9e7","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Don't split up SRFs when choosing to postpone SELECT output expressions.\n\nIn commit 9118d03a8cca3d97 we taught the planner to postpone evaluation of\nset-returning functions in a SELECT's targetlist until after any sort done\nto satisfy ORDER BY.  However, if we postpone some SRFs this way while\nothers do not get postponed (because they're sort or group key columns)\nwe will break the traditional behavior by which all SRFs in the tlist run\nin-step during ExecTargetList(), so that you get the least common multiple\nof their periods not the product.  Fix make_sort_input_target() so it will\nnot split up SRF evaluation in such cases.\n\nThere is still a hazard of similar odd behavior if there's a SRF in a\ngrouping column and another one that isn't, but that was true before\nand we're just trying to preserve bug-compatibility with the traditional\nbehavior.  This whole area is overdue to be rethought and reimplemented,\nbut we'll try to avoid changing behavior until then.\n\nPer report from Regina Obe.","distinct":true,"url":"https://api.github.com/repos/amitlan/postgres/commits/d543170f2fdd6d9845aaf91dc0f6be7a2bf0d9e7"},{"sha":"c94959d4110a1965472956cfd631082a96f64a84","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Fix DROP OPERATOR to reset oprcom/oprnegate links to the dropped operator.\n\nThis avoids leaving dangling links in pg_operator; which while fairly\nharmless are also unsightly.\n\nWhile we're at it, simplify OperatorUpd, which went through\nheap_modify_tuple for no very good reason considering it had already made\na tuple copy it could just scribble on.\n\nRoma Sokolov, reviewed by Tomas Vondra, additional hacking by Robert Haas\nand myself.","distinct":true,"url":"https://api.github.com/repos/amitlan/postgres/commits/c94959d4110a1965472956cfd631082a96f64a84"},{"sha":"fb8d2a7f57d87102f0a95025fbf1cad9c341739b","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"In PL/Tcl, make database errors return additional info in the errorCode.\n\nTcl has a convention for returning additional info about an error in a\nglobal variable named errorCode.  Up to now PL/Tcl has ignored that,\nbut this patch causes database errors caught by PL/Tcl to fill in\nerrorCode with useful information from the ErrorData struct.\n\nJim Nasby, reviewed by Pavel Stehule and myself","distinct":true,"url":"https://api.github.com/repos/amitlan/postgres/commits/fb8d2a7f57d87102f0a95025fbf1cad9c341739b"},{"sha":"cd37bb78599dcf24cd22a124ce9174b5e2a76880","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Improve PL/Tcl errorCode facility by providing decoded name for SQLSTATE.\n\nWe don't really want to encourage people to write numeric SQLSTATEs in\nprograms; that's unreadable and error-prone.  Copy plpgsql's infrastructure\nfor converting between SQLSTATEs and exception names shown in Appendix A,\nand modify examples in tests and documentation to do it that way.","distinct":true,"url":"https://api.github.com/repos/amitlan/postgres/commits/cd37bb78599dcf24cd22a124ce9174b5e2a76880"},{"sha":"9f73a2f6d1c1305cf0dc749dbf631cffe26beda0","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Fix PL/Tcl for vpath builds.\n\nCommit cd37bb78599dcf24 works for in-tree builds, but not so much for\nVPATH.  Per buildfarm.","distinct":true,"url":"https://api.github.com/repos/amitlan/postgres/commits/9f73a2f6d1c1305cf0dc749dbf631cffe26beda0"},{"sha":"676265eb7b57ba5bfae859630b909e6045893b68","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Update time zone data files to tzdata release 2016c.\n\nDST law changes in Azerbaijan, Chile, Haiti, Palestine, and Russia (Altai,\nAstrakhan, Kirov, Sakhalin, Ulyanovsk regions).  Historical corrections\nfor Lithuania, Moldova, Russia (Kaliningrad, Samara, Volgograd).\n\nAs of 2015b, the keepers of the IANA timezone database started to use\nnumeric time zone abbreviations (e.g., \"+04\") instead of inventing\nabbreviations not found in the wild like \"ASTT\".  This causes our rather\nold copy of zic to whine \"warning: time zone abbreviation differs from\nPOSIX standard\" several times during \"make install\".  This warning is\nharmless according to the IANA folk, and I don't see any problems with\nthese abbreviations in some simple tests; but it seems like now would be\na good time to update our copy of the tzcode stuff.  I'll look into that\nsoon.","distinct":true,"url":"https://api.github.com/repos/amitlan/postgres/commits/676265eb7b57ba5bfae859630b909e6045893b68"},{"sha":"76281aa9647e6a5dfc646514554d0f519e3b8a58","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Avoid a couple of zero-divide scenarios in the planner.\n\ncost_subplan() supposed that the given subplan must have plan_rows > 0,\nwhich as far as I can tell was true until recent refactoring of the\ncode in createplan.c; but now that code allows the Result for a provably\nempty subquery to have plan_rows = 0.  Rather than undo that change,\nput in a clamp to prevent zero divide.\n\nget_cheapest_fractional_path() likewise supposed that best_path->rows > 0.\nThis assumption has been wrong for longer.  It's actually harmless given\nIEEE float math, because a positive value divided by zero gives +Infinity\nand compare_fractional_path_costs() will do the right thing with that.\nStill, best not to assume that.\n\nfinal_cost_nestloop() also seems to have some risks in this area, so\nborrow the clamping logic already present in the mergejoin cost functions.\n\nLastly, remove unnecessary clamp_row_est() in planner.c's calls to\nget_number_of_groups().  The only thing that function does with path_rows\nis pass it to estimate_num_groups() which already has an internal clamp,\nso we don't need the extra call; and if we did, the callers are arguably\nthe wrong place for it anyway.\n\nFirst two items reported by Piotr Stefaniak, the others are products\nof my nosing around for similar problems.  No back-patch since there's\nno evidence that problems arise in the back branches.","distinct":true,"url":"https://api.github.com/repos/amitlan/postgres/commits/76281aa9647e6a5dfc646514554d0f519e3b8a58"},{"sha":"221619ad69b7e060041796a1974fbb0eeb9542d7","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Modernize zic's test for valid timezone abbreviations.\n\nWe really need to sync all of our IANA-derived timezone code with upstream,\nbut that's going to be a large patch and I certainly don't care to shove\nsuch a thing into stable branches immediately before a release.  As a\nstopgap, copy just the tzcode2016c logic that checks validity of timezone\nabbreviations.  This prevents getting multiple \"time zone abbreviation\ndiffers from POSIX standard\" bleats with tzdata 2014b and later.","distinct":true,"url":"https://api.github.com/repos/amitlan/postgres/commits/221619ad69b7e060041796a1974fbb0eeb9542d7"},{"sha":"29b6123ecb4113e366325245cec5a5c221dae691","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"First-draft release notes for 9.5.2.\n\nAs usual, the release notes for other branches will be made by cutting\nthese down, but put them up for community review first.","distinct":true,"url":"https://api.github.com/repos/amitlan/postgres/commits/29b6123ecb4113e366325245cec5a5c221dae691"},{"sha":"af4472bcb88ab36b9abbe7fd5858e570a65a2d1a","author":{"email":"883768b6dd2c42aea0031b24be8a2da40fef4b64@anarazel.de","name":"Andres Freund"},"message":"Change various Gin*Is* macros to return 0/1.\n\nReturning the direct result of bit arithmetic, in a macro intended to be\nused in a boolean manner, can be problematic if the return value is\nstored in a variable of type 'bool'. If bool is implemented using C99's\n_Bool, that can lead to comparison failures if the variable is then\ncompared again with the expression (see ginStepRight() for an example\nthat fails), as _Bool forces the result to be 0/1. That happens in some\nconfigurations of newer MSVC compilers.  It's also problematic when\nstoring the result of such an expression in a narrower type.\n\nSeveral gin macros have been declared in that style since gin's initial\ncommit in 8a3631f8d86.\n\nThere's a lot more macros like this, but this is the only one causing\nregression test failures; and I don't want to commit and backpatch a\nlarger patch with lots of conflicts just before the next set of minor\nreleases.\n\nDiscussion: 20150811154237.GD17575@awork2.anarazel.de\nBackpatch: All supported branches","distinct":true,"url":"https://api.github.com/repos/amitlan/postgres/commits/af4472bcb88ab36b9abbe7fd5858e570a65a2d1a"},{"sha":"1a7a43672bf2939dda93a27d498349e7a4aa3c14","author":{"email":"883768b6dd2c42aea0031b24be8a2da40fef4b64@anarazel.de","name":"Andres Freund"},"message":"Don't use !! but != 0/NULL to force boolean evaluation.\n\nI introduced several uses of !! to force bit arithmetic to be boolean,\nbut per discussion the project prefers != 0/NULL.\n\nDiscussion: CA+TgmoZP5KakLGP6B4vUjgMBUW0woq_dJYi0paOz-My0Hwt_vQ@mail.gmail.com","distinct":true,"url":"https://api.github.com/repos/amitlan/postgres/commits/1a7a43672bf2939dda93a27d498349e7a4aa3c14"},{"sha":"a6c845946dac5c1f26cf8729cf61f1d852f75484","author":{"email":"883768b6dd2c42aea0031b24be8a2da40fef4b64@anarazel.de","name":"Andres Freund"},"message":"pg_rewind: Close backup_label file descriptor.\n\nThis was a relatively harmless leak, as createBackupLabel() is only\ncalled once per pg_rewind invocation.\n\nAuthor: Michael Paquier\nReported-By: Michael Paquier\nDiscussion: CAB7nPqRnOw30gOXe2_SPLjh37bgm4V+txbYAPwoXb97nGQ297w@mail.gmail.com\nBackpatch: 9.5, where pg_rewind was introduced","distinct":true,"url":"https://api.github.com/repos/amitlan/postgres/commits/a6c845946dac5c1f26cf8729cf61f1d852f75484"},{"sha":"9f7c527af308dcdaba2f0ff9d362d672e8886fb1","author":{"email":"883768b6dd2c42aea0031b24be8a2da40fef4b64@anarazel.de","name":"Andres Freund"},"message":"Fix LWLockReportWaitEnd() parameter list to be (void).\n\nPreviously it was an \"old style\" function declaration.","distinct":true,"url":"https://api.github.com/repos/amitlan/postgres/commits/9f7c527af308dcdaba2f0ff9d362d672e8886fb1"},{"sha":"408f0438531eec17ac62f91fc23f72bcfc48dd36","author":{"email":"883768b6dd2c42aea0031b24be8a2da40fef4b64@anarazel.de","name":"Andres Freund"},"message":"pg_rewind: fsync target data directory.\n\nPreviously pg_rewind did not fsync any files. That's problematic, given\nthat the target directory is modified. If the database was started\nafterwards, 2ce439f33 luckily already caused the data directory to be\nsynced to disk at postmaster startup; reducing the scope of the problem.\n\nTo fix, use initdb -S, at the end of the pg_rewind run. It doesn't seem\nworthwhile to duplicate the code into pg_rewind, and initdb -S is\nalready used that way by pg_upgrade.\n\nReported-By: Andres Freund\nAuthor: Michael Paquier, somewhat edited by me\nDiscussion: 20160310034352.iuqgvpmg5qmnxtkz@alap3.anarazel.de\n    CAB7nPqSytVG1o4S3S2pA1O=692ekurJ+fckW2PywEG3sNw54Ow@mail.gmail.com\nBackpatch: 9.5, where pg_rewind was introduced","distinct":true,"url":"https://api.github.com/repos/amitlan/postgres/commits/408f0438531eec17ac62f91fc23f72bcfc48dd36"},{"sha":"fa09f8935156533584b4e215bdf70ec1ff968dad","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Clamp adjusted ndistinct to positive integer in estimate_hash_bucketsize().\n\nThis avoids a possible divide-by-zero in the following calculation,\nand rounding the number to an integer seems like saner behavior anyway.\nAssuming IEEE math, the division would yield +Infinity which would get\nreplaced by 1.0 at the bottom of the function, so nothing really\ninteresting would ensue; but avoiding divide-by-zero seems like a\ngood idea on general principles.\n\nPer report from Piotr Stefaniak.  No back-patch since this seems\nmostly cosmetic.","distinct":true,"url":"https://api.github.com/repos/amitlan/postgres/commits/fa09f8935156533584b4e215bdf70ec1ff968dad"},{"sha":"d65b665d524a67273b075f468bf3d60ce31f4040","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Guard against zero vardata.rel->tuples in estimate_hash_bucketsize().\n\nIf the referenced rel was proven empty, we'd compute 0/0 here, which\nresults in the function returning NaN.  That's a bit more serious\nthan the other zero-divide case.  Still, it only seems to be possible\nin HEAD, so no back-patch.\n\nPer report from Piotr Stefaniak.  I looked through the rest of selfuncs.c\nand found no other likely trouble spots.","distinct":true,"url":"https://api.github.com/repos/amitlan/postgres/commits/d65b665d524a67273b075f468bf3d60ce31f4040"},{"sha":"499a50571c72f41bb1365970d55dae5c8afcb6ba","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Release notes for 9.5.2, 9.4.7, 9.3.12, 9.2.16, 9.1.21.","distinct":true,"url":"https://api.github.com/repos/amitlan/postgres/commits/499a50571c72f41bb1365970d55dae5c8afcb6ba"},{"sha":"d12e5bb79bb535c2df13b76cd7d01f0bb8dc8e4d","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Code and docs review for commit 3187d6de0e5a9e805b27c48437897e8c39071d45.\n\nFix up check for high-bit-set characters, which provoked \"comparison is\nalways true due to limited range of data type\" warnings on some compilers,\nand was unlike the way we do it elsewhere anyway.  Fix omission of \"$\"\nfrom the set of valid identifier continuation characters.  Get rid of\nsanitize_text(), which was utterly inconsistent with any other error report\nanywhere in the system, and wasn't even well designed on its own terms\n(double-quoting the result string without escaping contained double quotes\ndoesn't seem very well thought out).  Fix up error messages, which didn't\nfollow the message style guidelines very well, and were overly specific in\nsituations where the actual mistake might not be what they said.  Improve\ndocumentation.\n\n(I started out just intending to fix the compiler warning, but the more\nI looked at the patch the less I liked it.)","distinct":true,"url":"https://api.github.com/repos/amitlan/postgres/commits/d12e5bb79bb535c2df13b76cd7d01f0bb8dc8e4d"},{"sha":"86ebf30fd6d8964bbd5d48db053b0a7ff709a0d7","author":{"email":"d3eaa418a359156a10c6383b2e3a44959960ecf6@snowman.net","name":"Stephen Frost"},"message":"Reset plan->row_security_env and planUserId\n\nIn the plancache, we check if the environment we planned the query under\nhas changed in a way which requires us to re-plan, such as when the user\nfor whom the plan was prepared changes and RLS is being used (and,\ntherefore, there may be different policies to apply).\n\nUnfortunately, while those values were set and checked, they were not\nbeing reset when the query was re-planned and therefore, in cases where\nwe change role, re-plan, and then change role again, we weren't\nre-planning again.  This leads to potentially incorrect policies being\napplied in cases where role-specific policies are used and a given query\nis planned under one role and then executed under other roles, which\ncould happen under security definer functions or when a common user and\nquery is planned initially and then re-used across multiple SET ROLEs.\n\nFurther, extensions which made use of CopyCachedPlan() may suffer from\nsimilar issues as the RLS-related fields were not properly copied as\npart of the plan and therefore RevalidateCachedQuery() would copy in the\ncurrent settings without invalidating the query.\n\nFix by using the same approach used for 'search_path', where we set the\ncorrect values in CompleteCachedPlan(), check them early on in\nRevalidateCachedQuery() and then properly reset them if re-planning.\nAlso, copy through the values during CopyCachedPlan().\n\nPointed out by Ashutosh Bapat.  Reviewed by Michael Paquier.\n\nBack-patch to 9.5 where RLS was introduced.\n\nSecurity: CVE-2016-2193","distinct":true,"url":"https://api.github.com/repos/amitlan/postgres/commits/86ebf30fd6d8964bbd5d48db053b0a7ff709a0d7"},{"sha":"3e1338475ffc2eac25de60a9de9ce689b763aced","author":{"email":"3c84f0de6f8a0f296d36cdd9f57fa166641c96b1@alvh.no-ip.org","name":"Alvaro Herrera"},"message":"Add missing checks to some of pageinspect's BRIN functions\n\nbrin_page_type() and brin_metapage_info() did not enforce being called\nby superuser, like other pageinspect functions that take bytea do.\nSince they don't verify the passed page thoroughly, it is possible to\nuse them to read the server memory with a carefully crafted bytea value,\nup to a file kilobytes from where the input bytea is located.\n\nHave them throw errors if called by a non-superuser.\n\nReport and initial patch: Andreas Seltenreich\n\nSecurity: CVE-2016-3065","distinct":true,"url":"https://api.github.com/repos/amitlan/postgres/commits/3e1338475ffc2eac25de60a9de9ce689b763aced"}]}