GitHub PushEvent at 2014-02-17 13:45:59
Repository: postgres
Actor: michaelpq
Payload: {"shas":[["f65233755ca5d01f49137b37f6a78b46acc83484","c50e6bf7013fce877ffb25104d778a36de31e297@gmx.net","Fix whitespace","Peter Eisentraut",false],["f31005e340c55948df6ab64370ce5cf202935f89","c50e6bf7013fce877ffb25104d778a36de31e297@gmx.net","doc: Disable indentation of XHTML output\n\nIndenting the XHTML output can lead to incorrect rendering.  This only\naffects the build via XSLT.","Peter Eisentraut",false],["ddfc9cb054abed4d08cc2709c9b2197dab96f449","ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","Assert(IsTransactionState()) in RelationIdGetRelation().\n\nCommit 42c80c696e9c8323841180029cc62741c21bd356 added an\nAssert(IsTransactionState()) in SearchCatCache(), to catch\nany code that thought it could do a catcache lookup outside\ntransactions.  Extend the same idea to relcache lookups.","Tom Lane",false],["45e1b6c4c490a173208f98f4babc03b8fc69439e","02e0a999c50b1f88df7a8f5a04e1b76b35ea6a88@dunslane.net","Alphabeticize list in OBJS definition in utils/adt Makefile.","Andrew Dunstan",false],["8de3e410faa06ab20ec1aa6d0abb0a2c040261ba","ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","In RelationClearRelation, postpone cache reload if !IsTransactionState().\n\nWe may process relcache flush requests during transaction startup or\nshutdown.  In general it's not terribly safe to do catalog access at those\ntimes, so the code's habit of trying to immediately revalidate unflushable\nrelcache entries is risky.  Although there are no field trouble reports\nthat are positively traceable to this, we have been able to demonstrate\nfailure of the assertions recently added in RelationIdGetRelation() and\nSearchCatCache().  On the other hand, it seems safe to just postpone\nrevalidation of the cache entry until we're inside a valid transaction.\nThe one case where this is questionable is where we're exiting a\nsubtransaction and the outer transaction is holding the relcache entry open\n--- but if we made any significant changes to the rel inside such a\nsubtransaction, we've got problems anyway.  There are mechanisms in place\nto prevent that (to wit, locks for cross-session cases and\nCheckTableNotInUse() for intra-session cases), so let's trust to those\nmechanisms to keep us out of trouble.","Tom Lane",false],["e001030c2711c0fb65cf72813f16a8eb26483c16","ac1e0af1ee8efe15f889b38482e897ff7d0f0432@iki.fi","Fix thinko in comment.\n\nAmit Langote","Heikki Linnakangas",false],["dbc649fd773e7e16458bfbec2611bf15f4355bc4","ac1e0af1ee8efe15f889b38482e897ff7d0f0432@iki.fi","Speed up \"rare & frequent\" type GIN queries.\n\nIf you have a GIN query like \"rare & frequent\", we currently fetch all the\nitems that match either rare or frequent, call the consistent function for\neach item, and let the consistent function filter out items that only match\none of the terms. However, if we can deduce that \"rare\" must be present for\nthe overall qual to be true, we can scan all the rare items, and for each\nrare item, skip over to the next frequent item with the same or greater TID.\nThat greatly speeds up \"rare & frequent\" type queries.\n\nTo implement that, introduce the concept of a tri-state consistent function,\nwhere the 3rd value is MAYBE, indicating that we don't know if that term is\npresent. Operator classes only provide a boolean consistent function, so we\nsimulate the tri-state consistent function by calling the boolean function\nseveral times, with the MAYBE arguments set to all combinations of TRUE and\nFALSE. Testing all combinations is only feasible for a small number of MAYBE\narguments, but it is envisioned that we'll provide a way for operator\nclasses to provide a native tri-state consistent function, which can be much\nmore efficient. But that is not included in this patch.\n\nWe were already using that trick to for lossy pages, calling the consistent\nfunction with the lossy entry set to TRUE and FALSE. Now that we have the\ntri-state consistent function, use it for lossy pages too.\n\nAlexander Korotkov, with fair amount of refactoring by me.","Heikki Linnakangas",false],["6aa2bdf6a01ce099e315cb313396ca4b8415321b","ac1e0af1ee8efe15f889b38482e897ff7d0f0432@iki.fi","Initialize the entryRes array between each call to triConsistent.\n\nThe shimTriConstistentFn, which calls the opclass's consistent function with\nall combinations of TRUE/FALSE for any MAYBE argument, modifies the entryRes\narray passed by the caller. Change startScanKey to re-initialize it between\neach call to accommodate that.\n\nIt's actually a bad habit by shimTriConsistentFn to modify its argument. But\nthe only caller that doesn't already re-initialize the entryRes array was\nstartScanKey, and it's easy for startScanKey to do so. Add a comment to\nshimTriConsistentFn about that.\n\nNote: this does not give a free pass to opclass-provided consistent\nfunctions to modify the entryRes argument; shimTriConsistent assumes that\nthey don't, even though it does it itself.\n\nWhile at it, refactor startScanKey to allocate the requiredEntries and\nadditionalEntries after it knows exactly how large they need to be. Saves a\nlittle bit of memory, and looks nicer anyway.\n\nPer complaint by Tom Lane, buildfarm and the pg_trgm regression test.","Heikki Linnakangas",false],["66c04c981dfe7c1d1e633dddcecf01982d0bde65","c50e6bf7013fce877ffb25104d778a36de31e297@gmx.net","Mark some more variables as static or include the appropriate header\n\nDetected by clang's -Wmissing-variable-declarations.\n\nFrom: Andres Freund <andres@anarazel.de>","Peter Eisentraut",false],["cfa1b4a711dd03f824a9c3ab50911e61419d1eeb","d3eaa418a359156a10c6383b2e3a44959960ecf6@snowman.net","Minor pg_dump improvements\n\nImprove pg_dump by checking results on various fgetc() calls which\npreviously were unchecked, ditto for ftello.  Also clean up a couple\nof very minor memory leaks by waiting to allocate structures until\nafter the initial check(s).\n\nIssues spotted by Coverity.","Stephen Frost",false],["01025d80a16c747641386e2909deb81e2f9423a6","9f4ca770b638615ac5c3e0d2da16b77c80c2f2c6@hagander.net","Avoid printing uninitialized filename variable in verbose mode\n\nWhen using verbose mode for pg_basebackup, in tar format sent to\nstdout, we'd print an unitialized buffer as the filename.\n\nReported by Pontus Lundkvist","Magnus Hagander",false],["8198a321c9ea2072c5acde438f4d19638e04f6f2","9f4ca770b638615ac5c3e0d2da16b77c80c2f2c6@hagander.net","Limit pg_basebackup progress output to 1/second\n\nThis prevents pg_basebackup from generating excessive output when\ndumping large clusters. The status is now updated once / second,\nstill making it possible to see that there is progress happening,\nbut limiting the total bandwidth.\n\nMika Eloranta, reviewed by Sawada Masahiko and Oskari Saarenmaa","Magnus Hagander",false],["5e8e794e3be9fbeddf6f2e2c0515dd0f04c784ec","d3eaa418a359156a10c6383b2e3a44959960ecf6@snowman.net","Focus on ftello result < 0 instead of errno\n\nRather than reset errno (or just hope that its cleared already),\ncheck just the result of the ftello for < 0 to determine if there\nwas an issue.\n\nOversight by me, pointed out by Tom.","Stephen Frost",false],["dfb1e9bdc0d0a506899b11038c7fce9631cac9fe","d3eaa418a359156a10c6383b2e3a44959960ecf6@snowman.net","Further pg_dump / ftello improvements\n\nMake ftello error-checking consistent to all calls and remove a\nbit of ftello-related code which has been #if 0'd out since 2001.\n\nNote that we are not concerned with the ftello() call under\nsnprintf() failing as it is just building a string to call\nexit_horribly() with; printing -1 in such a case is fine.","Stephen Frost",false],["6c2744f1d3a0d2e456f8d52776c976da3eb8d3a0","ac1e0af1ee8efe15f889b38482e897ff7d0f0432@iki.fi","Use memmove() instead of memcpy() for copying overlapping regions.\n\nIn commit d2495f272cd164ff075bee5c4ce95aed11338a36, I fixed this bug in\nto_tsquery(), but missed the fact that plainto_tsquery() has the same bug.","Heikki Linnakangas",false],["d699ba41349e4ef397222a7223606fa03f4c4870","ac1e0af1ee8efe15f889b38482e897ff7d0f0432@iki.fi","Fix WakeupWaiters() to not wake up an exclusive locker unnecessarily.\n\nWakeupWaiters() is supposed to wake up all LW_WAIT_UNTIL_FREE waiters of\nthe slot, but the loop incorrectly also woke up the first LW_EXCLUSIVE\nwaiter, if there was no LW_WAIT_UNTIL_FREE waiters in the queue.\n\nNoted by Andres Freund. This code is new in 9.4, so no backpatching.","Heikki Linnakangas",false],["2895415205d86cc7ab55acab5f90fd70a7c68f3c","ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","Don't generate plain-text HISTORY and src/test/regress/README anymore.\n\nProviding this information as plain text was doubtless worth the trouble\nten years ago, but it seems likely that hardly anyone reads it in this\nformat anymore.  And the effort required to maintain these files (in the\nform of extra-complex markup rules in the relevant parts of the SGML\ndocumentation) is significant.  So, let's stop doing that and rely solely\non the other documentation formats.\n\nPer discussion, the plain-text INSTALL instructions might still be worth\ntheir keep, so we continue to generate that file.\n\nRather than remove HISTORY and src/test/regress/README from distribution\ntarballs entirely, replace them with simple stub files that tell the reader\nwhere to find the relevant documentation.  This is mainly to avoid possibly\nbreaking packaging recipes that expect these files to exist.\n\nBack-patch to all supported branches, because simplifying the markup\nrequirements for release notes won't help much unless we do it in all\nbranches.","Tom Lane",false],["d3c4c471553265e7517be24bae64b81967f6df40","c50e6bf7013fce877ffb25104d778a36de31e297@gmx.net","scripts: Remove newlines from end of generated SQL\n\nThis results in spurious empty lines in the server log.  Instead, add\nthe newlines only when printing out the --echo output.  In some cases,\nthis was already done, leading to two newlines being printed.  Clean\nthat up as well.\n\nFrom: Fabrízio de Royes Mello <fabriziomello@gmail.com>","Peter Eisentraut",false],["cba6ffaef3987211fb31ba869eb2a476bad6f6d3","ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","Cygwin build fixes.\n\nGet rid of use of dlltool for linking the main postgres executable.\ndlltool is obsolete and we'd prefer to stop depending on it.\n\nAlso, include $(LDAP_LIBS_FE) in $(libpq_pgport).  (It's not clear that\nthis is really needed, or why it's not a linker bug if it is needed.\nBut reports are that it's needed on current Cygwin.)\n\nWe might want to back-patch this if it works, but first let's see\nwhat the buildfarm thinks.\n\nMarco Atzeri","Tom Lane",false],["846e91e0223cf9f2821c3ad4dfffffbb929cb027","ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","Get rid of use of dlltool in Mingw builds.\n\nWe are almost completely out of the dlltool game, if this works.\n\nHiroshi Inoue","Tom Lane",false]],"size":68,"ref":"refs/heads/master","head":"0983315b1d37cc17b2174dad87449d8402e357ee"}