{"push_id":663625585,"size":511,"distinct_size":511,"ref":"refs/heads/master","head":"9660710e2f5bbbf1b18640fbc5edcceafe7a10ad","before":"dc01efa5ccdd9804b0c97d4d9b651ba9360ebb11","commits":[{"sha":"272923a0a6956187471df4f032eee06559520390","author":{"email":"ac1e0af1ee8efe15f889b38482e897ff7d0f0432@iki.fi","name":"Heikki Linnakangas"},"message":"Simplify the way OpenSSL renegotiation is initiated in server.\n\nAt least in all modern versions of OpenSSL, it is enough to call\nSSL_renegotiate() once, and then forget about it. Subsequent SSL_write()\nand SSL_read() calls will finish the handshake.\n\nThe SSL_set_session_id_context() call is unnecessary too. We only have\none SSL context, and the SSL session was created with that to begin with.","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/272923a0a6956187471df4f032eee06559520390"},{"sha":"80788a431e9bff06314a054109fdea66ac538199","author":{"email":"ac1e0af1ee8efe15f889b38482e897ff7d0f0432@iki.fi","name":"Heikki Linnakangas"},"message":"Simplify waiting logic in reading from / writing to client.\n\nThe client socket is always in non-blocking mode, and if we actually want\nblocking behaviour, we emulate it by sleeping and retrying. But we have\nretry loops at different layers for reads and writes, which was confusing.\nTo simplify, remove all the sleeping and retrying code from the lower\nlevels, from be_tls_read and secure_raw_read and secure_raw_write, and put\nall the logic in secure_read() and secure_write().","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/80788a431e9bff06314a054109fdea66ac538199"},{"sha":"33e879c4e9f485405fc19b663392d8635714d020","author":{"email":"ac1e0af1ee8efe15f889b38482e897ff7d0f0432@iki.fi","name":"Heikki Linnakangas"},"message":"Fix broken #ifdef for __sparcv8\n\nRob Rowan. Backpatch to all supported versions, like the patch that added\nthe broken #ifdef.","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/33e879c4e9f485405fc19b663392d8635714d020"},{"sha":"80986e85aafd64165efc7f45b330f2f213713032","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Avoid returning undefined bytes in chkpass_in().\n\nWe can't really fix the problem that the result is defined to depend on\nrandom(), so it is still going to fail the \"unstable input conversion\"\ntest in parse_type.c.  However, we can at least satify valgrind.  (It\nlooks like this code used to be valgrind-clean, actually, until somebody\ndid a careless s/strncpy/strlcpy/g on it.)\n\nIn passing, let's just make real sure that chkpass_out doesn't overrun\nits output buffer.\n\nNo need for backpatch, I think, since this is just to satisfy debugging\ntools.\n\nAsif Naeem","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/80986e85aafd64165efc7f45b330f2f213713032"},{"sha":"64cdbbc48cade73d7b0831444a62e19fd4a342f8","author":{"email":"c50e6bf7013fce877ffb25104d778a36de31e297@gmx.net","name":"Peter Eisentraut"},"message":"pg_regress: Write processed input/*.source into output dir\n\nBefore, it was writing the processed files into the input directory,\nwhich is incorrect in a vpath build.","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/64cdbbc48cade73d7b0831444a62e19fd4a342f8"},{"sha":"c5b31e29f0128b1c3c1caeeef81b0986cebdcd03","author":{"email":"02e0a999c50b1f88df7a8f5a04e1b76b35ea6a88@dunslane.net","name":"Andrew Dunstan"},"message":"Minor housekeeping on JSON docs.","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/c5b31e29f0128b1c3c1caeeef81b0986cebdcd03"},{"sha":"08361cea2b333189fa3736f2dc6452cef654923d","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Fix null-pointer-deref crash while doing COPY IN with check constraints.\n\nIn commit bf7ca15875988a88e97302e012d7c4808bef3ea9 I introduced an\nassumption that an RTE referenced by a whole-row Var must have a valid eref\nfield.  This is false for RTEs constructed by DoCopy, and there are other\nplaces taking similar shortcuts.  Perhaps we should make all those places\ngo through addRangeTableEntryForRelation or its siblings instead of having\nad-hoc logic, but the most reliable fix seems to be to make the new code in\nExecEvalWholeRowVar cope if there's no eref.  We can reasonably assume that\nthere's no need to insert column aliases if no aliases were provided.\n\nAdd a regression test case covering this, and also verifying that a sane\ncolumn name is in fact available in this situation.\n\nAlthough the known case only crashes in 9.4 and HEAD, it seems prudent to\nback-patch the code change to 9.2, since all the ingredients for a similar\nfailure exist in the variant patch applied to 9.3 and 9.2.\n\nPer report from Jean-Pierre Pelletier.","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/08361cea2b333189fa3736f2dc6452cef654923d"},{"sha":"cef30974dec2c052170b80eff1fe4b9bb285e903","author":{"email":"1f6acd02e97f7332f0e624e7be5170a1e771cb87@postgresql.org","name":"Fujii Masao"},"message":"Correct the path of pg_lzcompress.c in doc.\n\nCommit 40bede5 moved pg_lzcompress.c to src/common, but forgot to\nupdate its path in doc. This commit fixes that oversight.","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/cef30974dec2c052170b80eff1fe4b9bb285e903"},{"sha":"e983c4d1aa42d613542cf222e222b034918374b1","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Rationalize the APIs of array element/slice access functions.\n\nThe four functions array_ref, array_set, array_get_slice, array_set_slice\nhave traditionally declared their array inputs and results as being of type\n\"ArrayType *\".  This is a lie, and has been since Berkeley days, because\nthey actually also support \"fixed-length array\" types such as \"name\" and\n\"point\"; not to mention that the inputs could be toasted.  These values\nshould be declared Datum instead to avoid confusion.  The current coding\nalready risks possible misoptimization by compilers, and it'll get worse\nwhen \"expanded\" array representations become a valid alternative.\n\nHowever, there's a fair amount of code using array_ref and array_set with\narrays that *are* known to be ArrayType structures, and there might be more\nsuch places in third-party code.  Rather than cluttering those call sites\nwith PointerGetDatum/DatumGetArrayTypeP cruft, what I did was to rename the\nexisting functions to array_get_element/array_set_element, fix their\nsignatures, then reincarnate array_ref/array_set as backwards compatibility\nwrappers.\n\narray_get_slice/array_set_slice have no such constituency in the core code,\nand probably not in third-party code either, so I just changed their APIs.","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/e983c4d1aa42d613542cf222e222b034918374b1"},{"sha":"2c75531a6cc49a56afbd5619c36b3daccbe243fa","author":{"email":"ac1e0af1ee8efe15f889b38482e897ff7d0f0432@iki.fi","name":"Heikki Linnakangas"},"message":"In the SSL test suite, use a root CA cert that won't expire (so quickly)\n\nAll the other certificates were created to be valid for 10000 days, because\nwe don't want to have to recreate them. But I missed the root CA cert, and\nthe pre-created certificates included in the repository expired in January.\nFix, and re-create all the certificates.","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/2c75531a6cc49a56afbd5619c36b3daccbe243fa"},{"sha":"9e3ad1aac52454569393a947c06be0d301749362","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Use fast path in plpgsql's RETURN/RETURN NEXT in more cases.\n\nexec_stmt_return() and exec_stmt_return_next() have fast-path code for\nhandling a simple variable reference (i.e. \"return var\") without going\nthrough the full expression evaluation machinery.  For some reason,\npl_gram.y was under the impression that this fast path only applied for\nrecord/row variables; but in reality code for handling regular scalar\nvariables has been there all along.  Adjusting the logic to allow that\ncode to be used actually results in a net savings of code in pl_gram.y\n(by eliminating some redundancy), and it buys a measurable though not\nvery impressive amount of speedup.\n\nNoted while fooling with my expanded-array patch, wherein this makes a much\nbigger difference because it enables returning an expanded array variable\nwithout an extra flattening step.  But AFAICS this is a win regardless,\nso commit it separately.","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/9e3ad1aac52454569393a947c06be0d301749362"},{"sha":"1c2b7c0879d83ff79e4adf2c0a883df92b713da4","author":{"email":"ac1e0af1ee8efe15f889b38482e897ff7d0f0432@iki.fi","name":"Heikki Linnakangas"},"message":"Restore the SSL_set_session_id_context() call to OpenSSL renegotiation.\n\nThis reverts the removal of the call in commit (272923a0). It turns out it\nwasn't superfluous after all: without it, renegotiation fails if a client\ncertificate was used. The rest of the changes in that commit are still OK\nand not reverted.\n\nPer investigation of bug #12769 by Arne Scheffer, although this doesn't fix\nthe reported bug yet.","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/1c2b7c0879d83ff79e4adf2c0a883df92b713da4"},{"sha":"c478959a009a926ec441f355219eae18537e648c","author":{"email":"ac1e0af1ee8efe15f889b38482e897ff7d0f0432@iki.fi","name":"Heikki Linnakangas"},"message":"Fix comment in libpq OpenSSL code about why a substitue BIO is used.\n\nThe comment was copy-pasted from the backend code along with the\nimplementation, but libpq has different reasons for using the BIO.","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/c478959a009a926ec441f355219eae18537e648c"},{"sha":"cb66f495f5d0c204f051971f2c549d5c3ac850ea","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Fix misuse of memcpy() in check_ip().\n\nThe previous coding copied garbage into a local variable, pretty much\nensuring that the intended test of an IPv6 connection address against a\npromoted IPv4 address from pg_hba.conf would never match.  The lack of\nfield complaints likely indicates that nobody realized this was supposed\nto work, which is unsurprising considering that no user-facing docs suggest\nit should work.\n\nIn principle this could have led to a SIGSEGV due to reading off the end of\nmemory, but since the source address would have pointed to somewhere in the\nfunction's stack frame, that's quite unlikely.  What led to discovery of\nthe bug is Hugo Osvaldo Barrera's report of a crash after an OS upgrade,\nwhich is probably because he is now running a system in which memcpy raises\nabort() upon detecting overlapping source and destination areas.  (You'd\nhave to additionally suppose some things about the stack frame layout to\narrive at this conclusion, but it seems plausible.)\n\nThis has been broken since the code was added, in commit f3aec2c7f51904e7,\nso back-patch to all supported branches.","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/cb66f495f5d0c204f051971f2c549d5c3ac850ea"},{"sha":"c923e82a231ebfe7c4329984c68819e26837bee6","author":{"email":"bc8b30e646d18e0af86ef37f859648a650cc276d@postgresql.org","name":"Kevin Grittner"},"message":"Eliminate unnecessary NULL checks in picksplit method of intarray.\n\nWhere these checks were being done there was no code path which\ncould leave them NULL.\n\nMichael Paquier per Coverity","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/c923e82a231ebfe7c4329984c68819e26837bee6"},{"sha":"5d6c2405f4bae6c87533d981d6a47587db501220","author":{"email":"cc4ab156f0be9feefe10b35a552fd319cd7679ae@postgresql.org","name":"Robert Haas"},"message":"Improve pg_check_dir code and comments.\n\nAvoid losing errno if readdir() fails and closedir() works.  Consistently\nreturn 4 rather than 3 if both a lost+found directory and other files are\nfound, rather than returning one value or the other depending on the\norder of the directory listing.  Update comments to match the actual\nbehavior.\n\nThese oversights date to commits 6f03927fce038096f53ca67eeab9adb24938f8a6\nand 17f15239325a88581bb4f9cf91d38005f1f52d69.\n\nMarco Nenciarini","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/5d6c2405f4bae6c87533d981d6a47587db501220"},{"sha":"2e105def09f27d49c1761abab06b427cfaa5d304","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Remove code to match IPv4 pg_hba.conf entries to IPv4-in-IPv6 addresses.\n\nIn investigating yesterday's crash report from Hugo Osvaldo Barrera, I only\nlooked back as far as commit f3aec2c7f51904e7 where the breakage occurred\n(which is why I thought the IPv4-in-IPv6 business was undocumented).  But\nactually the logic dates back to commit 3c9bb8886df7d56a and was simply\nbroken by erroneous refactoring in the later commit.  A bit of archives\nexcavation shows that we added the whole business in response to a report\nthat some 2003-era Linux kernels would report IPv4 connections as having\nIPv4-in-IPv6 addresses.  The fact that we've had no complaints since 9.0\nseems to be sufficient confirmation that no modern kernels do that, so\nlet's just rip it all out rather than trying to fix it.\n\nDo this in the back branches too, thus essentially deciding that our\neffective behavior since 9.0 is correct.  If there are any platforms on\nwhich the kernel reports IPv4-in-IPv6 addresses as such, yesterday's fix\nwould have made for a subtle and potentially security-sensitive change in\nthe effective meaning of IPv4 pg_hba.conf entries, which does not seem like\na good thing to do in minor releases.  So let's let the post-9.0 behavior\nstand, and change the documentation to match it.\n\nIn passing, I failed to resist the temptation to wordsmith the description\nof pg_hba.conf IPv4 and IPv6 address entries a bit.  A lot of this text\nhasn't been touched since we were IPv4-only.","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/2e105def09f27d49c1761abab06b427cfaa5d304"},{"sha":"d17b6df239e6eebf288969e931cdbe8076d1fe12","author":{"email":"ac1e0af1ee8efe15f889b38482e897ff7d0f0432@iki.fi","name":"Heikki Linnakangas"},"message":"Fix knn-GiST queue comparison function to return heap tuples first.\n\nThe part of the comparison function that was supposed to keep heap tuples\nahead of index items was backwards. It would not lead to incorrect results,\nbut it is more efficient to return heap tuples first, before scanning more\nindex pages, when both have the same distance.\n\nAlexander Korotkov","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/d17b6df239e6eebf288969e931cdbe8076d1fe12"},{"sha":"931bf3eb9b203ca02d729f5122a44cc250c27695","author":{"email":"ac1e0af1ee8efe15f889b38482e897ff7d0f0432@iki.fi","name":"Heikki Linnakangas"},"message":"Fix a bug in pairing heap removal code.\n\nAfter removal, the next_sibling pointer of a node was sometimes incorrectly\nleft to point to another node in the heap, which meant that a node was\nsometimes linked twice into the heap. Surprisingly that didn't cause any\ncrashes in my testing, but it was clearly wrong and could easily segfault\nin other scenarios.\n\nAlso always keep the prev_or_parent pointer as NULL on the root node. That\nwas not a correctness issue AFAICS, but let's be tidy.\n\nAdd a debugging function, to dump the contents of a pairing heap as a\nstring. It's #ifdef'd out, as it's not used for anything in any normal\ncode, but it was highly useful in debugging this. Let's keep it handy for\nfurther reference.","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/931bf3eb9b203ca02d729f5122a44cc250c27695"},{"sha":"abe45a9b315d7b3739f442597f570f9454bd466d","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Fix EXPLAIN output for cases where parent table is excluded by constraints.\n\nThe previous coding in EXPLAIN always labeled a ModifyTable node with the\nname of the target table affected by its first child plan.  When originally\nwritten, this was necessarily the parent table of the inheritance tree,\nso everything was unconfusing.  But when we added NO INHERIT constraints,\nit became possible for the parent table to be deleted from the plan by\nconstraint exclusion while still leaving child tables present.  This led to\nthe ModifyTable plan node being labeled with the first surviving child,\nwhich was deemed confusing.  Fix it by retaining the parent table's RT\nindex in a new field in ModifyTable.\n\nEtsuro Fujita, reviewed by Ashutosh Bapat and myself","distinct":true,"url":"https://api.github.com/repos/Distrotech/postgresql/commits/abe45a9b315d7b3739f442597f570f9454bd466d"}]}