{"push_id":1951877945,"size":11,"distinct_size":1,"ref":"refs/heads/commitfest/14/1221","head":"b5ee2fa44cb1f87f1a93b484808ed8ef93fa345f","before":"952cd573a1ddf48ffd017ab15ad9d57203a99c77","commits":[{"sha":"ce5dcf54b942a469194ae390730f803b3f3fb928","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Improve docs about numeric formatting patterns (to_char/to_number).\n\nThe explanation about \"0\" versus \"9\" format characters was confusing\nand arguably wrong; the discussion of sign handling wasn't very good\neither.  Notably, while it's accurate to say that \"FM\" strips leading\nzeroes in date/time values, what it really does with numeric values\nis to strip *trailing* zeroes, and then only if you wrote \"9\" rather\nthan \"0\".  Per gripes from Erwin Brandstetter.\n\nDiscussion: https://postgr.es/m/CAGHENJ7jgRbTn6nf48xNZ=FHgL2WQ4X8mYsUAU57f-vq8PubEw@mail.gmail.com\nDiscussion: https://postgr.es/m/CAGHENJ45ymd=GOCu1vwV9u7GmCR80_5tW0fP9C_gJKbruGMHvQ@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/ce5dcf54b942a469194ae390730f803b3f3fb928"},{"sha":"2e8841a577b83f9da903345f9830e881f84eed3c","author":{"name":"CommitFest Bot","email":"aab6a594935fe5db0d690bc154b19f642bfbe9d7@cputube.org"},"message":"Merge branch 'master' of git://git.postgresql.org/git/postgresql","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/2e8841a577b83f9da903345f9830e881f84eed3c"},{"sha":"3452dc5240da43e833118484e1e9b4894d04431c","author":{"name":"Robert Haas","email":"93159bdbbeed5b47be970d58edfbdf1c3ce55e4c@postgresql.org"},"message":"Push tuple limits through Gather and Gather Merge.\n\nIf we only need, say, 10 tuples in total, then we certainly don't need\nmore than 10 tuples from any single process.  Pushing down the limit\nlets workers exit early when possible.  For Gather Merge, there is\nan additional benefit: a Sort immediately below the Gather Merge can\nbe done as a bounded sort if there is an applicable limit.\n\nRobert Haas and Tom Lane\n\nDiscussion: http://postgr.es/m/CA+TgmoYa3QKKrLj5rX7UvGqhH73G1Li4B-EKxrmASaca2tFu9Q@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/3452dc5240da43e833118484e1e9b4894d04431c"},{"sha":"bf11e7ee2e3607bb67d25aec73aa53b2d7e9961b","author":{"name":"Robert Haas","email":"93159bdbbeed5b47be970d58edfbdf1c3ce55e4c@postgresql.org"},"message":"Propagate sort instrumentation from workers back to leader.\n\nUp until now, when parallel query was used, no details about the\nsort method or space used by the workers were available; details\nwere shown only for any sorting done by the leader.  Fix that.\n\nCommit 1177ab1dabf72bafee8f19d904cee3a299f25892 forced the test case\nadded by commit 1f6d515a67ec98194c23a5db25660856c9aab944 to run\nwithout parallelism; now that we have this infrastructure, allow\nthat again, with a little tweaking to make it pass with and without\nforce_parallel_mode.\n\nRobert Haas and Tom Lane\n\nDiscussion: http://postgr.es/m/CA+Tgmoa2VBZW6S8AAXfhpHczb=Rf6RqQ2br+zJvEgwJ0uoD_tQ@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/bf11e7ee2e3607bb67d25aec73aa53b2d7e9961b"},{"sha":"1a880e151abd2f85bf3d986e7b386d21620888dc","author":{"name":"CommitFest Bot","email":"aab6a594935fe5db0d690bc154b19f642bfbe9d7@cputube.org"},"message":"Merge branch 'master' of git://git.postgresql.org/git/postgresql","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/1a880e151abd2f85bf3d986e7b386d21620888dc"},{"sha":"43006508d2459aaa5390ac53e998c895bd276a18","author":{"name":"CommitFest Bot","email":"aab6a594935fe5db0d690bc154b19f642bfbe9d7@cputube.org"},"message":"Merge branch 'master' of git://git.postgresql.org/git/postgresql","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/43006508d2459aaa5390ac53e998c895bd276a18"},{"sha":"2e70d6b5e99b7e7b53336b1838f869bbea1b5024","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Teach libpq to detect integer overflow in the row count of a PGresult.\n\nAdding more than 1 billion rows to a PGresult would overflow its ntups and\ntupArrSize fields, leading to client crashes.  It'd be desirable to use\nwider fields on 64-bit machines, but because all of libpq's external APIs\nuse plain \"int\" for row counters, that's going to be hard to accomplish\nwithout an ABI break.  Given the lack of complaints so far, and the general\npain that would be involved in using such huge PGresults, let's settle for\njust preventing the overflow and reporting a useful error message if it\ndoes happen.  Also, for a couple more lines of code we can increase the\nthreshold of trouble from INT_MAX/2 to INT_MAX rows.\n\nTo do that, refactor pqAddTuple() to allow returning an error message that\nreplaces the default assumption that it failed because of out-of-memory.\n\nAlong the way, fix PQsetvalue() so that it reports all failures via\npqInternalNotice().  It already did so in the case of bad field number,\nbut neglected to report anything for other error causes.\n\nBecause of the potential for crashes, this seems like a back-patchable\nbug fix, despite the lack of field reports.\n\nMichael Paquier, per a complaint from Igor Korot.\n\nDiscussion: https://postgr.es/m/CA+FnnTxyLWyjY1goewmJNxC==HQCCF4fKkoCTa9qR36oRAHDPw@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/2e70d6b5e99b7e7b53336b1838f869bbea1b5024"},{"sha":"cd37a0089ba8422f2a3f9cbdfe040de0a3850f90","author":{"name":"CommitFest Bot","email":"aab6a594935fe5db0d690bc154b19f642bfbe9d7@cputube.org"},"message":"Merge branch 'master' of git://git.postgresql.org/git/postgresql","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/cd37a0089ba8422f2a3f9cbdfe040de0a3850f90"},{"sha":"6cbee65eee20c144bb4de169c6802f20e76785b0","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Doc: document libpq's restriction to INT_MAX rows in a PGresult.\n\nAs long as PQntuples, PQgetvalue, etc, use \"int\" for row numbers, we're\npretty much stuck with this limitation.  The documentation formerly stated\nthat the result of PQntuples \"might overflow on 32-bit operating systems\",\nwhich is just nonsense: that's not where the overflow would happen, and\nif you did reach an overflow it would not be on a 32-bit machine, because\nyou'd have OOM'd long since.\n\nDiscussion: https://postgr.es/m/CA+FnnTxyLWyjY1goewmJNxC==HQCCF4fKkoCTa9qR36oRAHDPw@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/6cbee65eee20c144bb4de169c6802f20e76785b0"},{"sha":"1771d2f0dbbca26311b22a60d6abdd53c86a1fc8","author":{"name":"CommitFest Bot","email":"aab6a594935fe5db0d690bc154b19f642bfbe9d7@cputube.org"},"message":"Merge branch 'master' of git://git.postgresql.org/git/postgresql","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/1771d2f0dbbca26311b22a60d6abdd53c86a1fc8"},{"sha":"b5ee2fa44cb1f87f1a93b484808ed8ef93fa345f","author":{"name":"CommitFest Bot","email":"aab6a594935fe5db0d690bc154b19f642bfbe9d7@cputube.org"},"message":"Automatic commit for Commitfest submission #1221.\n\nThis commit was automatically generated and includes a Travis control file\nto tell travis-ci.org what to do with it.  This branch will be overwritten\neach time a new patch version is posted or master changes.\n\nCommitfest entry: https://commitfest.postgresql.org/14/1221\nPatches fetched from: https://www.postgresql.org/message-id/20170816184019.2d12f81a%40wp.localdomain","distinct":true,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/b5ee2fa44cb1f87f1a93b484808ed8ef93fa345f"}]}
{"actor":{"display_login":"postgresql-cfbot"}}