{"push_id":2904219940,"size":23,"distinct_size":1,"ref":"refs/heads/commitfest/19/1711","head":"ae19262e9112734ea07a113ea77ab33ce111e411","before":"0aaf8db8e9cf80877079d604eeeecbeca4533049","commits":[{"sha":"f025bd2ddd07a46560a5fbe8dd4790f153ead705","author":{"name":"Thomas Munro","email":"1ff054ef0838bf068a4b7c40eef026e560a37025@postgresql.org"},"message":"Use size_t consistently in dsa.{ch}.\n\nTakeshi Ideriha complained that there is a mixture of Size and size_t\nin dsa.c and corresponding header.  Let's use size_t.  Back-patch to 10\nwhere dsa.c landed, to make future back-patching easy.\n\nDiscussion: https://postgr.es/m/4E72940DA2BF16479384A86D54D0988A6F19ABD9%40G01JPEXMBKW04","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/f025bd2ddd07a46560a5fbe8dd4790f153ead705"},{"sha":"e3b7a6d165d42b59b2432c415d7e4a284a645e89","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Rationalize Query_for_list_of_[relations] query names in tab-complete.c.\n\nThe previous convention was to use names based on the set of relkinds being\nselected for, which was not at all helpful for maintenance, especially\nsince people had been quite inconsistent about whether to change the names\nwhen they changed the relkinds being selected for.  Instead, use names\nbased on the functionality we need the relation to have, following the\nmodel established by Query_for_list_of_updatables.\n\nWhile at it, sort the list of Query constants a bit better; it had the\ndistinct air of code-assembled-by-dartboard before.\n\nDiscussion: https://postgr.es/m/14830.1537481254@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/e3b7a6d165d42b59b2432c415d7e4a284a645e89"},{"sha":"121213d9d8527f880f153e4a032ee1a4cd43833f","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Improve tab completion for ANALYZE, EXPLAIN, and VACUUM.\n\nPreviously, we made no attempt to provide tab completion in these\nstatements' optional parenthesized options lists.  This patch teaches\npsql to do so.\n\nTo prevent the option completions from being offered after we've already\nseen a complete parenthesized option list, it's necessary to improve\nword_matches() so that it allows a wildcard '*' in the middle of an\nalternative, not only at the end as formerly.  That requires only a\nlittle more code than before, and it allows us to test for \"incomplete\nparenthesized options\" with a test like\n\n    else if (HeadMatches2(\"EXPLAIN\", \"(*\") &&\n             !HeadMatches2(\"EXPLAIN\", \"(*)\"))\n\nIn addition, add some logic to offer column names in the context of\n\"ANALYZE tablename ( ...\", and likewise for VACUUM.  This isn't real\ncomplete; it won't offer column names again after a comma.  But it's\nbetter than before, and it doesn't take much code.\n\nJustin Pryzby, reviewed at various times by Álvaro Herrera, Arthur\nZakirov, and Edmund Horner; some additional fixups by me\n\nDiscussion: https://postgr.es/m/20180529000623.GA21896@telsasoft.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/121213d9d8527f880f153e4a032ee1a4cd43833f"},{"sha":"e8fe426baa9c242d8dbd4eab1d963e952c9172f4","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Fix bogus tab-completion rule for CREATE PUBLICATION.\n\nYou can't use \"FOR TABLE\" as a single Matches argument, because readline\nwill consider that input to be two words not one.  It's necessary to make\nthe pattern contain two arguments.\n\nThe case accidentally worked anyway because the words_after_create\ntest fired ... but only for the first such table name.\n\nNoted by Edmund Horner, though this isn't exactly his proposed fix.\nBackpatch to v10 where the faulty code came in.\n\nDiscussion: https://postgr.es/m/CAMyN-kDe=gBmHgxWwUUaXuwK+p+7g1vChR7foPHRDLE592nJPQ@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/e8fe426baa9c242d8dbd4eab1d963e952c9172f4"},{"sha":"f77de4b0c0ad8c351223929b6fb3ee5c300a9979","author":{"name":"Bruce Momjian","email":"9ae9c44b775ee9b29f4f502415e02e61a9b1a6a0@momjian.us"},"message":"docs:  remove use of escape strings and use bytea hex output\n\nstandard_conforming_strings defaulted to 'on' in PG 9.1.\nbytea_output defaulted to 'hex' in PG 9.0.\n\nReported-by: André Hänsel\n\nDiscussion: https://postgr.es/m/12e601d447ac$345994a0$9d0cbde0$@webkr.de\n\nBackpatch-through: 9.3","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/f77de4b0c0ad8c351223929b6fb3ee5c300a9979"},{"sha":"1f7fc7670c7e0051b47bb4a4d6b41ff9e8af53fa","author":{"name":"Bruce Momjian","email":"9ae9c44b775ee9b29f4f502415e02e61a9b1a6a0@momjian.us"},"message":"doc:  JIT is enabled by default in PG 12\n\nJIT was disabled by default in a PG 11 in a separate commit that will\nnormally not appear in the PG 12 git logs.  Therefore, create a PG 12\ndocument and mention the fact that JIT is enabled by default in this\nrelease.  (A similar change in parallelism was missed in a prior\nrelease.)\n\nReported-by: Andres Freund\n\nDiscussion: https://postgr.es/m/20180922000554.qukbhhlagpnopvko@alap3.anarazel.de\n\nBackpatch-through: head","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/1f7fc7670c7e0051b47bb4a4d6b41ff9e8af53fa"},{"sha":"4f3b38fe2bde72d59b7eab593ff72e0cebd9ecc6","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Get rid of explicit argument-count markings in tab-complete.c.\n\nThis replaces the \"TailMatchesN\" macros with just \"TailMatches\",\nand likewise \"HeadMatchesN\" becomes \"HeadMatches\" and \"MatchesN\"\nbecomes \"Matches\".  The various COMPLETE_WITH_LISTn macros are\nreduced to COMPLETE_WITH, and the single-item COMPLETE_WITH_CONST\nalso gets folded into that.  This eliminates a lot of minor\nannoyance in writing tab-completion rules.  Usefully, the compiled\ncode also gets a bit smaller (10% or so, on my machine).\n\nThe implementation depends on variadic macros, so we couldn't have\ndone this before we required C99.\n\nAndres Freund and Thomas Munro; some cosmetic cleanup by me.\n\nDiscussion: https://postgr.es/m/d8jo9djvm7h.fsf@dalvik.ping.uio.no","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/4f3b38fe2bde72d59b7eab593ff72e0cebd9ecc6"},{"sha":"db361db2fce7491303f49243f652c75c084f5a19","author":{"name":"Michael Paquier","email":"17b9e1c64588c7fa6419b4d29dc1f4426279ba01@paquier.xyz"},"message":"Make GUC wal_sender_timeout user-settable\n\nBeing able to use a value that can be changed on a connection basis is\nuseful with clusters distributed geographically, and makes failure\ndetection more flexible.  A note is added in the documentation about the\nuse of \"options\" in primary_conninfo, which can be hard to grasp for\nnewcomers with the need of two single quotes when listing a set of\nparameters.\n\nAuthor: Tsunakawa Takayuki\nReviewed-by: Masahiko Sawada, Michael Paquier\nDiscussion: https://postgr.es/m/0A3221C70F24FB45833433255569204D1FAAD3AE@G01JPEXMBYT05","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/db361db2fce7491303f49243f652c75c084f5a19"},{"sha":"2f39106a209e647d7b1895331fca115f9bb6ec8d","author":{"name":"Alexander Korotkov","email":"1c137998207470ad0f56303c4fc305487ec0232f@postgresql.org"},"message":"Replace CAS loop with single TAS in ProcArrayGroupClearXid()\n\nSingle pg_atomic_exchange_u32() is expected to be faster than loop of\npg_atomic_compare_exchange_u32().  Also, it would be consistent with\nclog group update code.\n\nDiscussion: https://postgr.es/m/CAPpHfdtxLsC-bqfxFcHswZ91OxXcZVNDBBVfg9tAWU0jvn1tQA%40mail.gmail.com\nReviewed-by: Amit Kapila","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/2f39106a209e647d7b1895331fca115f9bb6ec8d"},{"sha":"89b280e139c463c98eb33592216a123e89052d08","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Fix failure in WHERE CURRENT OF after rewinding the referenced cursor.\n\nIn a case where we have multiple relation-scan nodes in a cursor plan,\nsuch as a scan of an inheritance tree, it's possible to fetch from a\ngiven scan node, then rewind the cursor and fetch some row from an\nearlier scan node.  In such a case, execCurrent.c mistakenly thought\nthat the later scan node was still active, because ExecReScan hadn't\ndone anything to make it look not-active.  We'd get some sort of\nfailure in the case of a SeqScan node, because the node's scan tuple\nslot would be pointing at a HeapTuple whose t_self gets reset to\ninvalid by heapam.c.  But it seems possible that for other relation\nscan node types we'd actually return a valid tuple TID to the caller,\nresulting in updating or deleting a tuple that shouldn't have been\nconsidered current.  To fix, forcibly clear the ScanTupleSlot in\nExecScanReScan.\n\nAnother issue here, which seems only latent at the moment but could\neasily become a live bug in future, is that rewinding a cursor does\nnot necessarily lead to *immediately* applying ExecReScan to every\nscan-level node in the plan tree.  Upper-level nodes will think that\nthey can postpone that call if their child node is already marked\nwith chgParam flags.  I don't see a way for that to happen today in\na plan tree that's simple enough for execCurrent.c's search_plan_tree\nto understand, but that's one heck of a fragile assumption.  So, add\nsome logic in search_plan_tree to detect chgParam flags being set on\nnodes that it descended to/through, and assume that that means we\nshould consider lower scan nodes to be logically reset even if their\nReScan call hasn't actually happened yet.\n\nPer bug #15395 from Matvey Arye.  This has been broken for a long time,\nso back-patch to all supported branches.\n\nDiscussion: https://postgr.es/m/153764171023.14986.280404050547008575@wrigleys.postgresql.org","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/89b280e139c463c98eb33592216a123e89052d08"},{"sha":"73a60051379b35a0bec399edfe369c59e50cc775","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Doc: warn against using parallel restore with --load-via-partition-root.\n\nThis isn't terribly safe, and making it so doesn't seem like a small\nproject, so for the moment just warn against it.\n\nDiscussion: https://postgr.es/m/13624.1535486019@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/73a60051379b35a0bec399edfe369c59e50cc775"},{"sha":"d18f6674bd60e923bcdbf0fd916685b0a250c60f","author":{"name":"Noah Misch","email":"1db01d43e08596f43a65fb393d969b98ee5b4dc6@leadboat.com"},"message":"Initialize random() in bootstrap/stand-alone postgres and in initdb.\n\nThis removes a difference between the standard IsUnderPostmaster\nexecution environment and that of --boot and --single.  In a stand-alone\nbackend, \"SELECT random()\" always started at the same seed.\n\nOn a system capable of using posix shared memory, initdb could still\nconclude \"selecting dynamic shared memory implementation ... sysv\".\nCrashed --boot or --single postgres processes orphaned shared memory\nobjects having names that collided with the not-actually-random names\nthat initdb probed.  The sysv fallback appeared after ten crashes of\n--boot or --single postgres.  Since --boot and --single are rare in\nproduction use, systems used for PostgreSQL development are the\nprincipal candidate to notice this symptom.\n\nBack-patch to 9.3 (all supported versions).  PostgreSQL 9.4 introduced\ndynamic shared memory, but 9.3 does share the \"SELECT random()\" problem.\n\nReviewed by Tom Lane and Kyotaro HORIGUCHI.\n\nDiscussion: https://postgr.es/m/20180915221546.GA3159382@rfd.leadboat.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/d18f6674bd60e923bcdbf0fd916685b0a250c60f"},{"sha":"c62dd80cdf149e2792b13c13777a539f5abb0370","author":{"name":"Joe Conway","email":"1d6e1cf70ec6f9ab28d3ea4b27a49a77654d370e@joeconway.com"},"message":"Document aclitem functions and operators\n\naclitem functions and operators have been heretofore undocumented.\nFix that. While at it, ensure the non-operator aclitem functions have\npg_description strings.\n\nDoes not seem worthwhile to back-patch.\n\nAuthor: Fabien Coelho, with pg_description from John Naylor, and significant\nrefactoring and editorialization by me.\nReviewed by: Tom Lane\nDiscussion: https://postgr.es/m/flat/alpine.DEB.2.21.1808010825490.18204%40lancre","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/c62dd80cdf149e2792b13c13777a539f5abb0370"},{"sha":"87d9bbca13f9c6b8f6ee986f0e399cb83bd731d4","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Fix over-allocation of space for array_out()'s result string.\n\narray_out overestimated the space needed for its output, possibly by\na very substantial amount if the array is multi-dimensional, because\nof wrong order of operations in the loop that counts the number of\ncurly-brace pairs needed.  While the output string is normally\nshort-lived, this could still cause problems in extreme cases.\n\nAn additional minor error was that it counted one more delimiter than\nis actually needed.\n\nRepair those errors, add an Assert that the space is now correctly\ncalculated, and make some minor improvements in the comments.\n\nI also failed to resist the temptation to get rid of an integer\nmodulus operation per array element; a simple comparison is sufficient.\n\nThis bug dates clear back to Berkeley days, so back-patch to all\nsupported versions.\n\nKeiichi Hirobe, minor additional work by me\n\nDiscussion: https://postgr.es/m/CAH=EFxE9W0tRvQkixR2XJRRCToUYUEDkJZk6tnADXugPBRdcdg@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/87d9bbca13f9c6b8f6ee986f0e399cb83bd731d4"},{"sha":"60e612b602999e670f2d57a01e52799eaa903ca9","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Use ppoll(2), if available, to wait for input in pgbench.\n\nPreviously, pgbench always used select(2) for this purpose, but that's\nproblematic for very high client counts, because select() can't deal\nwith file descriptor numbers larger than FD_SETSIZE.  It's pretty common\nfor that to be only 1024 or so, whereas modern OSes can allow many more\nopen files than that.  Using poll(2) would surmount that problem, but it\ncreates another one: poll()'s timeout resolution is only 1ms, which is\npoor enough to cause problems with --rate specifications approaching or\nexceeding 1K TPS.\n\nOn platforms that have ppoll(2), which includes Linux and recent\nFreeBSD, we can use that to avoid the FD_SETSIZE problem without any\nloss of timeout resolution.  Hence, add configure logic to test for\nppoll(), and use it if available.\n\nThis patch introduces an abstraction layer into pgbench that could\nbe extended to support other kernel event-wait APIs such as kevents.\nBut actually adding such support is a matter for some future patch.\n\nDoug Rady, reviewed by Robert Haas and Fabien Coelho, and whacked around\na good bit more by me\n\nDiscussion: https://postgr.es/m/23D017C9-81B7-484D-8490-FD94DEC4DF59@amazon.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/60e612b602999e670f2d57a01e52799eaa903ca9"},{"sha":"7636e5c60fea83a9f3cd2ad278c0819b98941c74","author":{"name":"Andrew Dunstan","email":"02e0a999c50b1f88df7a8f5a04e1b76b35ea6a88@dunslane.net"},"message":"Fast default trigger and expand_tuple fixes\n\nEnsure that triggers get properly filled in tuples for the OLD value.\nAlso fix the logic of detecting missing null values. The previous logic\nfailed to detect a missing null column before the first missing column\nwith a default. Fixing this has simplified the logic a bit.\n\nRegression tests are added to test changes. This should ensure better\ncoverage of expand_tuple().\n\nOriginal bug reports, and some code and test scripts from Tomas Vondra\n\nBackpatch to release 11.","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/7636e5c60fea83a9f3cd2ad278c0819b98941c74"},{"sha":"52050ad8ebec8d831902f587314aa4f6aaa6d2c5","author":{"name":"Andres Freund","email":"883768b6dd2c42aea0031b24be8a2da40fef4b64@anarazel.de"},"message":"Make EXPLAIN output for JIT compilation more dense.\n\nA discussion about also reporting JIT compilation overhead on workers\nbrought unhappiness with the verbosity of the current explain format\nto light.  Make the text format more dense, and restructure the\nstructured output to mirror that more closely.\n\nAs we're re-jiggering the output format anyway: The denser format\nallows us to report all flags for JIT compilation (now also reporting\nPGJIT_EXPR and PGJIT_DEFORM), and report the total time in addition to\nthe individual times.\n\nPer complaint from Tom Lane.\n\nAuthor: Andres Freund\nDiscussion: https://postgr.es/m/27812.1537221015@sss.pgh.pa.us\nBackpatch: 11-, where JIT compilation was introduced","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/52050ad8ebec8d831902f587314aa4f6aaa6d2c5"},{"sha":"b076eb7669d7279d0f446305c2e12dffd6bc3347","author":{"name":"Andres Freund","email":"883768b6dd2c42aea0031b24be8a2da40fef4b64@anarazel.de"},"message":"auto_explain: Include JIT information if applicable.\n\nDue to my (Andres') omission auto_explain did not include information\nabout JIT compilation. Fix that.\n\nAuthor: Lukas Fittl\nDiscussion:\nhttps://postgr.es/m/CAP53PkzgSyoTCau0-5FNaM484B=uO8nLzma7L1ncWLb1=oVJQA@mail.gmail.com\nBackpatch: 11-, where JIT compilation was introduced","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/b076eb7669d7279d0f446305c2e12dffd6bc3347"},{"sha":"fd582317e10e26083b8c720598bfcdbf89787112","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Sync our Snowball stemmer dictionaries with current upstream.\n\nWe haven't touched these since text search functionality landed in core\nin 2007 :-(.  While the upstream project isn't a beehive of activity,\nthey do make additions and bug fixes from time to time.  Update our\ncopies of these files.\n\nAlso update our documentation about how to keep things in sync, since\nthey're not making distribution tarballs these days.  Fortunately,\ntheir source code turns out to be a breeze to build.\n\nNotable changes:\n\n* The non-UTF8 version of the hungarian stemmer now works in LATIN2\nnot LATIN1.\n\n* New stemmers have appeared for arabic, indonesian, irish, lithuanian,\nnepali, and tamil.  These all work in UTF8, and the indonesian and\nirish ones also work in LATIN1.\n\n(There are some new stemmers that I did not incorporate, mainly because\ntheir names don't match the underlying languages, suggesting that they're\nnot to be considered mainstream.)\n\nWorth noting: the upstream Nepali dictionary was contributed by\nArthur Zakirov.\n\ninitdb forced because the contents of snowball_create.sql have\nchanged.\n\nStill TODO: see about updating the stopword lists.\n\nArthur Zakirov, minor mods and doc work by me\n\nDiscussion: https://postgr.es/m/20180626122025.GA12647@zakirov.localdomain\nDiscussion: https://postgr.es/m/20180219140849.GA9050@zakirov.localdomain","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/fd582317e10e26083b8c720598bfcdbf89787112"},{"sha":"edb9797660541b217d23ae7c02b96b496d34fec4","author":{"name":"Michael Paquier","email":"17b9e1c64588c7fa6419b4d29dc1f4426279ba01@paquier.xyz"},"message":"Revoke pg_stat_statements_reset() permissions\n\nCommit 25fff40 has granted execute permission of the function\npg_stat_statements_reset() to default role \"pg_read_all_stats\", but this\nrole is meant to read statistics, and not to reset them.  The\npermissions on this function are revoked from \"pg_read_all_stats\".  The\nversion of pg_stat_statements is bumped up in consequence.\n\nAuthor: Haribabu Kommi\nReviewed-by: Michael Paquier, Amit Kapila\nDiscussion: https://postgr.es/m/CAJrrPGf5fCnKqXObpwGN9nMyD--tzOf-7LFCJiz59Z1wJ5qj9A@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/edb9797660541b217d23ae7c02b96b496d34fec4"}]}
{"actor":{"display_login":"postgresql-cfbot"}}