{"push_id":539645695,"size":91,"distinct_size":1,"ref":"refs/heads/transition","head":"4fdddd920d81c19197799504b5ea28b3417d0cc8","before":"47658bcf4de7980089b32f59d1ff8489805aeca9","commits":[{"sha":"de8e46f5f5785f4016aabf2aa231faa89a0746fb","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Suppress bogus statistics when pgbench failed to complete any transactions.\n\nCode added in 9.4 would attempt to divide by zero in such cases.\nNoted while testing fix for missing-pclose problem.","distinct":false,"url":"https://api.github.com/repos/kgrittn/postgres/commits/de8e46f5f5785f4016aabf2aa231faa89a0746fb"},{"sha":"66709133c7e5506be19bf56a82f45dd150f74732","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Fix off-by-one loop count in MapArrayTypeName, and get rid of static array.\n\nMapArrayTypeName would copy up to NAMEDATALEN-1 bytes of the base type\nname, which of course is wrong: after prepending '_' there is only room for\nNAMEDATALEN-2 bytes.  Aside from being the wrong result, this case would\nlead to overrunning the statically allocated work buffer.  This would be a\nsecurity bug if the function were ever used outside bootstrap mode, but it\nisn't, at least not in any currently supported branches.\n\nAside from fixing the off-by-one loop logic, this patch gets rid of the\nstatic work buffer by having MapArrayTypeName pstrdup its result; the sole\ncaller was already doing that, so this just requires moving the pstrdup\ncall.  This saves a few bytes but mainly it makes the API a lot cleaner.\n\nBack-patch on the off chance that there is some third-party code using\nMapArrayTypeName with less-secure input.  Pushing pstrdup into the function\nshould not cause any serious problems for such hypothetical code; at worst\nthere might be a short term memory leak.\n\nPer Coverity scanning.","distinct":false,"url":"https://api.github.com/repos/kgrittn/postgres/commits/66709133c7e5506be19bf56a82f45dd150f74732"},{"sha":"cb7b5c5c6f8df5fee936c6a26553427166cbdbfe","author":{"email":"9f4ca770b638615ac5c3e0d2da16b77c80c2f2c6@hagander.net","name":"Magnus Hagander"},"message":"Remove redundant sentence\n\nSpotted by David Johnston","distinct":false,"url":"https://api.github.com/repos/kgrittn/postgres/commits/cb7b5c5c6f8df5fee936c6a26553427166cbdbfe"},{"sha":"6964ad95d78a21e6d7aec9727ea9a0af68482c35","author":{"email":"9f4ca770b638615ac5c3e0d2da16b77c80c2f2c6@hagander.net","name":"Magnus Hagander"},"message":"Add missing documentation for some vcregress modes\n\nMichael Paquier","distinct":false,"url":"https://api.github.com/repos/kgrittn/postgres/commits/6964ad95d78a21e6d7aec9727ea9a0af68482c35"},{"sha":"cef0ae498ccbd4b166ee4fe6cb33612646fdc4b5","author":{"email":"9f4ca770b638615ac5c3e0d2da16b77c80c2f2c6@hagander.net","name":"Magnus Hagander"},"message":"Update .gitignore for pg_upgrade\n\nAdd Windows versions of generated scripts, and make sure we only\nignore the scripts int he root directory.\n\nMichael Paquier","distinct":false,"url":"https://api.github.com/repos/kgrittn/postgres/commits/cef0ae498ccbd4b166ee4fe6cb33612646fdc4b5"},{"sha":"c977b8cffc76be00fbaab76e3271e05104260ec7","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Fix poorly worded error message.\n\nAdam Brightwell, per report from Martín Marqués.","distinct":false,"url":"https://api.github.com/repos/kgrittn/postgres/commits/c977b8cffc76be00fbaab76e3271e05104260ec7"},{"sha":"c340494235111fb87e46b11ca6a87a7a43795f0f","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Fix another poorly worded error message.\n\nSpotted by Álvaro Herrera.","distinct":false,"url":"https://api.github.com/repos/kgrittn/postgres/commits/c340494235111fb87e46b11ca6a87a7a43795f0f"},{"sha":"ce01548d4fdbc06dce59f90a3e4598162b1e8ea1","author":{"email":"ac1e0af1ee8efe15f889b38482e897ff7d0f0432@iki.fi","name":"Heikki Linnakangas"},"message":"Clarify the regexp used to detect source files in MSVC builds.\n\nThe old pattern would match files with strange extensions like *.ry or\n*.lpp. Refactor it to only include files with known extensions, and to make\nit more readable.\n\nPer Andrew Dunstan's suggestion.","distinct":false,"url":"https://api.github.com/repos/kgrittn/postgres/commits/ce01548d4fdbc06dce59f90a3e4598162b1e8ea1"},{"sha":"fc2ac1fb41c2defb8caf825781af75db158fb7a9","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Allow CHECK constraints to be placed on foreign tables.\n\nAs with NOT NULL constraints, we consider that such constraints are merely\nreports of constraints that are being enforced by the remote server (or\nother underlying storage mechanism).  Their only real use is to allow\nplanner optimizations, for example in constraint-exclusion checks.  Thus,\nthe code changes here amount to little more than removal of the error that\nwas formerly thrown for applying CHECK to a foreign table.\n\n(In passing, do a bit of cleanup of the ALTER FOREIGN TABLE reference page,\nwhich had accumulated some weird decisions about ordering etc.)\n\nShigeru Hanada and Etsuro Fujita, reviewed by Kyotaro Horiguchi and\nAshutosh Bapat.","distinct":false,"url":"https://api.github.com/repos/kgrittn/postgres/commits/fc2ac1fb41c2defb8caf825781af75db158fb7a9"},{"sha":"f6dc6dd5ba54d52c0733aaafc50da2fbaeabb8b0","author":{"email":"1db01d43e08596f43a65fb393d969b98ee5b4dc6@leadboat.com","name":"Noah Misch"},"message":"Lock down regression testing temporary clusters on Windows.\n\nUse SSPI authentication to allow connections exclusively from the OS\nuser that launched the test suite.  This closes on Windows the\nvulnerability that commit be76a6d39e2832d4b88c0e1cc381aa44a7f86881\nclosed on other platforms.  Users of \"make installcheck\" or custom test\nharnesses can run \"pg_regress --config-auth=DATADIR\" to activate the\nsame authentication configuration that \"make check\" would use.\nBack-patch to 9.0 (all supported versions).\n\nSecurity: CVE-2014-0067","distinct":false,"url":"https://api.github.com/repos/kgrittn/postgres/commits/f6dc6dd5ba54d52c0733aaafc50da2fbaeabb8b0"},{"sha":"40c598fa15bef1ea10850aad80914ab797808106","author":{"email":"1db01d43e08596f43a65fb393d969b98ee5b4dc6@leadboat.com","name":"Noah Misch"},"message":"Fix previous commit for TAP test suites in VPATH builds.\n\nPer buildfarm member crake.  Back-patch to 9.4, where the TAP suites\nwere introduced.","distinct":false,"url":"https://api.github.com/repos/kgrittn/postgres/commits/40c598fa15bef1ea10850aad80914ab797808106"},{"sha":"c303e9e7e5d4ddf04526ed8e821ef4b1c3bc2d12","author":{"email":"883768b6dd2c42aea0031b24be8a2da40fef4b64@anarazel.de","name":"Andres Freund"},"message":"Fix (re-)starting from a basebackup taken off a standby after a failure.\n\nWhen starting up from a basebackup taken off a standby extra logic has\nto be applied to compute the point where the data directory is\nconsistent. Normal base backups use a WAL record for that purpose, but\nthat isn't possible on a standby.\n\nThat logic had a error check ensuring that the cluster's control file\nindicates being in recovery. Unfortunately that check was too strict,\ndisregarding the fact that the control file could also indicate that\nthe cluster was shut down while in recovery.\n\nThat's possible when the a cluster starting from a basebackup is shut\ndown before the backup label has been removed. When everything goes\nwell that's a short window, but when either restore_command or\nprimary_conninfo isn't configured correctly the window can get much\nwider. That's because inbetween reading and unlinking the label we\nrestore the last checkpoint from WAL which can need additional WAL.\n\nTo fix simply also allow starting when the control file indicates\n\"shutdown in recovery\". There's nicer fixes imaginable, but they'd be\nmore invasive.\n\nBackpatch to 9.2 where support for taking basebackups from standbys\nwas added.","distinct":false,"url":"https://api.github.com/repos/kgrittn/postgres/commits/c303e9e7e5d4ddf04526ed8e821ef4b1c3bc2d12"},{"sha":"26674c923d0ecbac2cda039433163d17584fae65","author":{"email":"1f6acd02e97f7332f0e624e7be5170a1e771cb87@postgresql.org","name":"Fujii Masao"},"message":"Remove odd blank line in comment.\n\nEtsuro Fujita","distinct":false,"url":"https://api.github.com/repos/kgrittn/postgres/commits/26674c923d0ecbac2cda039433163d17584fae65"},{"sha":"43b56171b1fbcba8a6309de755545e3c63ac25dd","author":{"email":"1db01d43e08596f43a65fb393d969b98ee5b4dc6@leadboat.com","name":"Noah Misch"},"message":"Recognize Makefile line continuations in fetchRegressOpts().\n\nBack-patch to 9.0 (all supported versions).  This is mere\nfuture-proofing in the context of the master branch, but commit\nf6dc6dd5ba54d52c0733aaafc50da2fbaeabb8b0 requires it of older branches.","distinct":false,"url":"https://api.github.com/repos/kgrittn/postgres/commits/43b56171b1fbcba8a6309de755545e3c63ac25dd"},{"sha":"72950dc1d02c6b44c6475485fd5ef8ac277bbdd0","author":{"email":"883768b6dd2c42aea0031b24be8a2da40fef4b64@anarazel.de","name":"Andres Freund"},"message":"Adjust valgrind suppression to the changes in 2c03216d8311.\n\nCRC computation is now done in XLogRecordAssemble.","distinct":false,"url":"https://api.github.com/repos/kgrittn/postgres/commits/72950dc1d02c6b44c6475485fd5ef8ac277bbdd0"},{"sha":"ccf292cd2ec16c69ddfee3bf72afe113a7595e00","author":{"email":"1f6acd02e97f7332f0e624e7be5170a1e771cb87@postgresql.org","name":"Fujii Masao"},"message":"Update .gitignore for config.cache.\n\nAlso add a comment about why regreesion.* aren't listed in .gitignore.\n\nJim Nasby","distinct":false,"url":"https://api.github.com/repos/kgrittn/postgres/commits/ccf292cd2ec16c69ddfee3bf72afe113a7595e00"},{"sha":"19e065c0492c34fbccbd2c3707ba68cff14195a3","author":{"email":"1f6acd02e97f7332f0e624e7be5170a1e771cb87@postgresql.org","name":"Fujii Masao"},"message":"Ensure variables live across calls in generate_series(numeric, numeric).\n\nIn generate_series_step_numeric(), the variables \"start_num\"\nand \"stop_num\" may be potentially freed until the next call.\nSo they should be put in the location which can survive across calls.\nBut previously they were not, and which could cause incorrect\nbehavior of generate_series(numeric, numeric). This commit fixes\nthis problem by copying them on multi_call_memory_ctx.\n\nAndrew Gierth","distinct":false,"url":"https://api.github.com/repos/kgrittn/postgres/commits/19e065c0492c34fbccbd2c3707ba68cff14195a3"},{"sha":"38628db8d8caff21eb6cf8d775c0b2d04cf07b9b","author":{"email":"1f6acd02e97f7332f0e624e7be5170a1e771cb87@postgresql.org","name":"Fujii Masao"},"message":"Add memory barriers for PgBackendStatus.st_changecount protocol.\n\nst_changecount protocol needs the memory barriers to ensure that\nthe apparent order of execution is as it desires. Otherwise,\nfor example, the CPU might rearrange the code so that st_changecount\nis incremented twice before the modification on a machine with\nweak memory ordering. This surprising result can lead to bugs.\n\nThis commit introduces the macros to load and store st_changecount\nwith the memory barriers. These are called before and after\nPgBackendStatus entries are modified or copied into private memory,\nin order to prevent CPU from reordering PgBackendStatus access.\n\nPer discussion on pgsql-hackers, we decided not to back-patch this\nto 9.4 or before until we get an actual bug report about this.\n\nPatch by me. Review by Robert Haas.","distinct":false,"url":"https://api.github.com/repos/kgrittn/postgres/commits/38628db8d8caff21eb6cf8d775c0b2d04cf07b9b"},{"sha":"ba94518aad23beb800b657bd0cc8c4e7ea43ca33","author":{"email":"ac1e0af1ee8efe15f889b38482e897ff7d0f0432@iki.fi","name":"Heikki Linnakangas"},"message":"Change how first WAL segment on new timeline after promotion is created.\n\nTwo changes:\n\n1. When copying a WAL segment from old timeline to create the first segment\non the new timeline, only copy up to the point where the timeline switch\nhappens, and zero-fill the rest. This avoids corner cases where we might\nthink that the copied WAL from the previous timeline belong to the new\ntimeline.\n\n2. If the timeline switch happens at a segment boundary, don't copy the\nwhole old segment to the new timeline. It's pointless, because it's 100%\nidentical to the old segment.","distinct":false,"url":"https://api.github.com/repos/kgrittn/postgres/commits/ba94518aad23beb800b657bd0cc8c4e7ea43ca33"},{"sha":"4a14f13a0abfbf7e7d44a3d2689444d1806aa9dc","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Improve hash_create's API for selecting simple-binary-key hash functions.\n\nPreviously, if you wanted anything besides C-string hash keys, you had to\nspecify a custom hashing function to hash_create().  Nearly all such\ncallers were specifying tag_hash or oid_hash; which is tedious, and rather\nerror-prone, since a caller could easily miss the opportunity to optimize\nby using hash_uint32 when appropriate.  Replace this with a design whereby\ncallers using simple binary-data keys just specify HASH_BLOBS and don't\nneed to mess with specific support functions.  hash_create() itself will\ntake care of optimizing when the key size is four bytes.\n\nThis nets out saving a few hundred bytes of code space, and offers\na measurable performance improvement in tidbitmap.c (which was not\nexploiting the opportunity to use hash_uint32 for its 4-byte keys).\nThere might be some wins elsewhere too, I didn't analyze closely.\n\nIn future we could look into offering a similar optimized hashing function\nfor 8-byte keys.  Under this design that could be done in a centralized\nand machine-independent fashion, whereas getting it right for keys of\nplatform-dependent sizes would've been notationally painful before.\n\nFor the moment, the old way still works fine, so as not to break source\ncode compatibility for loadable modules.  Eventually we might want to\nremove tag_hash and friends from the exported API altogether, since there's\nno real need for them to be explicitly referenced from outside dynahash.c.\n\nTeodor Sigaev and Tom Lane","distinct":false,"url":"https://api.github.com/repos/kgrittn/postgres/commits/4a14f13a0abfbf7e7d44a3d2689444d1806aa9dc"}]}