{"push_id":538948346,"size":27,"distinct_size":1,"ref":"refs/heads/create_matview_if_not_exists","head":"62008a682a3cd4277bc72e208b5fcac62506a298","before":"b7c7282bdb082835d4942aef0a0f2986122143e6","commits":[{"sha":"ae17897ce84e545fd5a042530055df728b2ca98f","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Assorted minor fixes for psql metacommand docs.\n\nDocument the long forms of \\H \\i \\ir \\o \\p \\r \\w ... apparently, we have\na long and dishonorable history of leaving out the unabbreviated names of\npsql backslash commands.\n\nAvoid saying \"Unix shell\"; we can just say \"shell\" with equal clarity,\nand not leave Windows users wondering whether the feature works for them.\n\nImprove consistency of documentation of \\g \\o \\w metacommands.  There's\nno reason to use slightly different wording or markup for each one.","distinct":false,"url":"https://api.github.com/repos/fabriziomello/postgres/commits/ae17897ce84e545fd5a042530055df728b2ca98f"},{"sha":"3b5a89c4820fb11c337838c1ad71e8e93f2937d1","author":{"email":"d65e86e9f63e8ebd237ae089e7c4417e05d5f9dd@postgresql.org","name":"Tatsuo Ishii"},"message":"Fix resource leak pointed out by Coverity.","distinct":false,"url":"https://api.github.com/repos/fabriziomello/postgres/commits/3b5a89c4820fb11c337838c1ad71e8e93f2937d1"},{"sha":"930fd68455576dada48521a6cef642caddea3c63","author":{"email":"ac1e0af1ee8efe15f889b38482e897ff7d0f0432@iki.fi","name":"Heikki Linnakangas"},"message":"Revert the GinMaxItemSize calculation so that we fit 3 tuples per page.\n\nCommit 36a35c55 changed the divisor from 3 to 6, for no apparent reason.\nReducing GinMaxItemSize like that created a dump/reload hazard: loading a\n9.3 database to 9.4 might fail with \"index row size XXX exceeds maximum 1352\nfor index ...\" error. Revert the change.\n\nWhile we're at it, make the calculation slightly more accurate. It used to\ndivide the available space on page by three, then subtract\nsizeof(ItemIdData), and finally round down. That's not totally accurate; the\nitem pointers for the three items are packed tight right after the page\nheader, but there is alignment padding after the item pointers. Change the\ncalculation to reflect that, like BTMaxItemSize does. I tested this with\ndifferent block sizes on systems with 4- and 8-byte alignment, and the value\nafter the final MAXALIGN_DOWN was the same with both methods on all\nconfigurations. So this does not make any difference currently, but let's be\ntidy.\n\nAlso add a comment explaining what the macro does.\n\nThis fixes bug #12292 reported by Robert Thaler. Backpatch to 9.4, where the\nbug was introduced.","distinct":false,"url":"https://api.github.com/repos/fabriziomello/postgres/commits/930fd68455576dada48521a6cef642caddea3c63"},{"sha":"3f88672a4e4d8e648d24ccc65937da61c7660854","author":{"email":"3c84f0de6f8a0f296d36cdd9f57fa166641c96b1@alvh.no-ip.org","name":"Alvaro Herrera"},"message":"Use TypeName to represent type names in certain commands\n\nIn COMMENT, DROP, SECURITY LABEL, and the new pg_get_object_address\nfunction, we were representing types as a list of names, same as other\nobjects; but types are special objects that require their own\nrepresentation to be totally accurate.  In the original COMMENT code we\nhad a note about fixing it which was lost in the course of c10575ff005.\nChange all those places to use TypeName instead, as suggested by that\ncomment.\n\nRight now the original coding doesn't cause any bugs, so no backpatch.\nIt is more problematic for proposed future code that operate with object\naddresses from the SQL interface; type details such as array-ness are\nlost when working with the degraded representation.\n\nThanks to Petr Jelínek and Dimitri Fontaine for offlist help on finding\na solution to a shift/reduce grammar conflict.","distinct":false,"url":"https://api.github.com/repos/fabriziomello/postgres/commits/3f88672a4e4d8e648d24ccc65937da61c7660854"},{"sha":"5b447ad3a98aa6f059ba467eb10a832eb1544985","author":{"email":"3c84f0de6f8a0f296d36cdd9f57fa166641c96b1@alvh.no-ip.org","name":"Alvaro Herrera"},"message":"Fix object_address expected output\n\nPer pink buildfarm","distinct":false,"url":"https://api.github.com/repos/fabriziomello/postgres/commits/5b447ad3a98aa6f059ba467eb10a832eb1544985"},{"sha":"a676201490c8113b4692562126c77a29dfd8dac1","author":{"email":"3c84f0de6f8a0f296d36cdd9f57fa166641c96b1@alvh.no-ip.org","name":"Alvaro Herrera"},"message":"Add pg_identify_object_as_address\n\nThis function returns object type and objname/objargs arrays, which can\nbe passed to pg_get_object_address.  This is especially useful because\nthe textual representation can be copied to a remote server in order to\nobtain the corresponding OID-based address.  In essence, this function\nis the inverse of recently added pg_get_object_address().\n\nCatalog version bumped due to the addition of the new function.\n\nAlso add docs to pg_get_object_address.","distinct":false,"url":"https://api.github.com/repos/fabriziomello/postgres/commits/a676201490c8113b4692562126c77a29dfd8dac1"},{"sha":"72dd233d3ef12da0f041bb3024deaa6d2950369c","author":{"email":"3c84f0de6f8a0f296d36cdd9f57fa166641c96b1@alvh.no-ip.org","name":"Alvaro Herrera"},"message":"pg_event_trigger_dropped_objects: Add name/args output columns\n\nThese columns can be passed to pg_get_object_address() and used to\nreconstruct the dropped objects identities in a remote server containing\nsimilar objects, so that the drop can be replicated.\n\nReviewed by Stephen Frost, Heikki Linnakangas, Abhijit Menon-Sen, Andres\nFreund.","distinct":false,"url":"https://api.github.com/repos/fabriziomello/postgres/commits/72dd233d3ef12da0f041bb3024deaa6d2950369c"},{"sha":"c168c885776cd5d815611c10633ca04f699744e3","author":{"email":"cc4ab156f0be9feefe10b35a552fd319cd7679ae@postgresql.org","name":"Robert Haas"},"message":"Don't tab-complete COMMENT ON ... IS with IS.\n\nIan Barwick","distinct":false,"url":"https://api.github.com/repos/fabriziomello/postgres/commits/c168c885776cd5d815611c10633ca04f699744e3"},{"sha":"ba66c9d0681f0c5ec834255fb4e7f6ef6b626747","author":{"email":"3c84f0de6f8a0f296d36cdd9f57fa166641c96b1@alvh.no-ip.org","name":"Alvaro Herrera"},"message":"Add missing pstrdup calls\n\nThe one for the OCLASS_COLLATION case was noticed by\nCLOBBER_CACHE_ALWAYS buildfarm members; the others I spotted by manual\ncode inspection.\n\nAlso remove a redundant check.","distinct":false,"url":"https://api.github.com/repos/fabriziomello/postgres/commits/ba66c9d0681f0c5ec834255fb4e7f6ef6b626747"},{"sha":"28551797a46c0ada035c34cf9cf2bc90448e3c26","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Improve consistency of parsing of psql's magic variables.\n\nFor simple boolean variables such as ON_ERROR_STOP, psql has for a long\ntime recognized variant spellings of \"on\" and \"off\" (such as \"1\"/\"0\"),\nand it also made a point of warning you if you'd misspelled the setting.\nBut these conveniences did not exist for other keyword-valued variables.\nIn particular, though ECHO_HIDDEN and ON_ERROR_ROLLBACK include \"on\" and\n\"off\" as possible values, none of the alternative spellings for those were\nrecognized; and to make matters worse the code would just silently assume\n\"on\" was meant for any unrecognized spelling.  Several people have reported\ngetting bitten by this, so let's fix it.  In detail, this patch:\n\n* Allows all spellings recognized by ParseVariableBool() for ECHO_HIDDEN\nand ON_ERROR_ROLLBACK.\n\n* Reports a warning for unrecognized values for COMP_KEYWORD_CASE, ECHO,\nECHO_HIDDEN, HISTCONTROL, ON_ERROR_ROLLBACK, and VERBOSITY.\n\n* Recognizes all values for all these variables case-insensitively;\npreviously there was a mishmash of case-sensitive and case-insensitive\nbehaviors.\n\nBack-patch to all supported branches.  There is a small risk of breaking\nexisting scripts that were accidentally failing to malfunction; but the\nconsensus is that the chance of detecting real problems and preventing\nfuture mistakes outweighs this.","distinct":false,"url":"https://api.github.com/repos/fabriziomello/postgres/commits/28551797a46c0ada035c34cf9cf2bc90448e3c26"},{"sha":"a486841eb11517e4a344fdebaf370f425a171c85","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Print more information about getObjectIdentityParts() failures.\n\nThis might help us debug what's happening on some buildfarm members.\n\nIn passing, reduce the message from ereport to elog --- it doesn't seem\nlike this should be a user-facing case, so not worth translating.","distinct":false,"url":"https://api.github.com/repos/fabriziomello/postgres/commits/a486841eb11517e4a344fdebaf370f425a171c85"},{"sha":"2f03ae69875ff27a9667a7ec4655434900b64e55","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Docs: improve descriptions of ISO week-numbering date features.\n\nUse the phraseology \"ISO 8601 week-numbering year\" in place of just\n\"ISO year\", and make related adjustments to other terminology.\n\nThe point of this change is that it seems some people see \"ISO year\"\nand think \"standard year\", whereupon they're surprised when constructs\nlike to_char(..., \"IYYY-MM-DD\") produce nonsensical results.  Perhaps\nhanging a few more adjectives on it will discourage them from jumping\nto false conclusions.  I put in an explicit warning against that\nspecific usage, too, though the main point is to discourage people\nwho haven't read this far down the page.\n\nIn passing fix some nearby markup and terminology inconsistencies.","distinct":false,"url":"https://api.github.com/repos/fabriziomello/postgres/commits/2f03ae69875ff27a9667a7ec4655434900b64e55"},{"sha":"7161b082bd9fc51e67a1031ea9d0313e8a48286b","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Don't run rowsecurity in parallel with other regression tests.\n\nThe short-lived event trigger in the rowsecurity test causes irreproducible\nfailures when the concurrent tests do something that the event trigger\ncan't cope with.  Per buildfarm.","distinct":false,"url":"https://api.github.com/repos/fabriziomello/postgres/commits/7161b082bd9fc51e67a1031ea9d0313e8a48286b"},{"sha":"f9769c719f7811146e8aafbd0ff6c666b128ecce","author":{"email":"9f4ca770b638615ac5c3e0d2da16b77c80c2f2c6@hagander.net","name":"Magnus Hagander"},"message":"Make path to pg_service.conf absolute in documentation\n\nThe system file is always in the absolute path /etc/, not relative.\n\nDavid Fetter","distinct":false,"url":"https://api.github.com/repos/fabriziomello/postgres/commits/f9769c719f7811146e8aafbd0ff6c666b128ecce"},{"sha":"d6657d2a107bee20d63ec2f776d873242f9355e9","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Treat negative values of recovery_min_apply_delay as having no effect.\n\nAt one point in the development of this feature, it was claimed that\nallowing negative values would be useful to compensate for timezone\ndifferences between master and slave servers.  That was based on a mistaken\nassumption that commit timestamps are recorded in local time; but of course\nthey're in UTC.  Nor is a negative apply delay likely to be a sane way of\ncoping with server clock skew.  However, the committed patch still treated\nnegative delays as doing something, and the timezone misapprehension\nsurvived in the user documentation as well.\n\nIf recovery_min_apply_delay were a proper GUC we'd just set the minimum\nallowed value to be zero; but for the moment it seems better to treat\nnegative settings as if they were zero.\n\nIn passing do some extra wordsmithing on the parameter's documentation,\nincluding correcting a second misstatement that the parameter affects\nprocessing of Restore Point records.\n\nIssue noted by Michael Paquier, who also provided the code patch; doc\nchanges by me.  Back-patch to 9.4 where the feature was introduced.","distinct":false,"url":"https://api.github.com/repos/fabriziomello/postgres/commits/d6657d2a107bee20d63ec2f776d873242f9355e9"},{"sha":"ccb161b66addc9d0ede31359c05f7e9df61ab8d4","author":{"email":"883768b6dd2c42aea0031b24be8a2da40fef4b64@anarazel.de","name":"Andres Freund"},"message":"Add pg_string_endswith as the start of a string helper library in src/common.\n\nBackpatch to 9.3 where src/common was introduce, because a bugfix that\nneeds to be backpatched, requires the function. Earlier branches will\nhave to duplicate the code.","distinct":false,"url":"https://api.github.com/repos/fabriziomello/postgres/commits/ccb161b66addc9d0ede31359c05f7e9df61ab8d4"},{"sha":"2c0a4858965f1375dadb45df9f3a054bfcb283f5","author":{"email":"883768b6dd2c42aea0031b24be8a2da40fef4b64@anarazel.de","name":"Andres Freund"},"message":"Prevent WAL files created by pg_basebackup -x/X from being archived again.\n\nWAL (and timeline history) files created by pg_basebackup did not\nmaintain the new base backup's archive status. That's currently not a\nproblem if the new node is used as a standby - but if that node is\npromoted all still existing files can get archived again.  With a high\nwal_keep_segment settings that can happen a significant time later -\nwhich is quite confusing.\n\nChange both the backend (for the -x/-X fetch case) and pg_basebackup\n(for -X stream) itself to always mark WAL/timeline files included in\nthe base backup as .done. That's in line with walreceiver.c doing so.\n\nThe verbosity of the pg_basebackup changes show pretty clearly that it\nneeds some refactoring, but that'd result in not be backpatchable\nchanges.\n\nBackpatch to 9.1 where pg_basebackup was introduced.\n\nDiscussion: 20141205002854.GE21964@awork2.anarazel.de","distinct":false,"url":"https://api.github.com/repos/fabriziomello/postgres/commits/2c0a4858965f1375dadb45df9f3a054bfcb283f5"},{"sha":"0398ece4c5baacc98f0fd46a731518b3ccb25bb3","author":{"email":"883768b6dd2c42aea0031b24be8a2da40fef4b64@anarazel.de","name":"Andres Freund"},"message":"Fix inconsequential fd leak in the new mark_file_as_archived() function.\n\nAs every error in mark_file_as_archived() will lead to a failure of\npg_basebackup the FD leak couldn't ever lead to a real problem.  It\nseems better to fix the leak anyway though, rather than silence\nCoverity, as the usage of the function might get extended or copied at\nsome point in the future.\n\nPointed out by Coverity.\n\nBackpatch to 9.2, like the relevant part of the previous patch.","distinct":false,"url":"https://api.github.com/repos/fabriziomello/postgres/commits/0398ece4c5baacc98f0fd46a731518b3ccb25bb3"},{"sha":"58bc4747be26f6849ca38e67e24abdd6aecba3b1","author":{"email":"883768b6dd2c42aea0031b24be8a2da40fef4b64@anarazel.de","name":"Andres Freund"},"message":"Add missing va_end() call to a early exit in dmetaphone.c's StringAt().\n\nPointed out by Coverity.\n\nBackpatch to all supported branches, the code has been that way for a\nlong while.","distinct":false,"url":"https://api.github.com/repos/fabriziomello/postgres/commits/58bc4747be26f6849ca38e67e24abdd6aecba3b1"},{"sha":"14570c28289f82030172c699ec877dd26d04940a","author":{"email":"883768b6dd2c42aea0031b24be8a2da40fef4b64@anarazel.de","name":"Andres Freund"},"message":"Remove superflous variable from xlogreader's XLogFindNextRecord().\n\nPointed out by Coverity.\n\nSince this is mere, and debatable, cosmetics I'm not backpatching\nthis.","distinct":false,"url":"https://api.github.com/repos/fabriziomello/postgres/commits/14570c28289f82030172c699ec877dd26d04940a"}]}