GitHub PushEvent at 2014-04-25 01:25:55
Repository: postgres
Actor: fabriziomello
Payload: {"shas":[["125ba2945aacde7713f3767b012c429c384f3b62","c50e6bf7013fce877ffb25104d778a36de31e297@gmx.net","doc: Fix DocBook table column count declaration\n\nThis was broken in 26cd1d7d9513b2b490efc746551ec5a786b56212.","Peter Eisentraut",false],["f0fedfe82c8adea78354652d67c027a1a8fbce88","ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","Allow polymorphic aggregates to have non-polymorphic state data types.\n\nBefore 9.4, such an aggregate couldn't be declared, because its final\nfunction would have to have polymorphic result type but no polymorphic\nargument, which CREATE FUNCTION would quite properly reject.  The\nordered-set-aggregate patch found a workaround: allow the final function\nto be declared as accepting additional dummy arguments that have types\nmatching the aggregate's regular input arguments.  However, we failed\nto notice that this problem applies just as much to regular aggregates,\ndespite the fact that we had a built-in regular aggregate array_agg()\nthat was known to be undeclarable in SQL because its final function\nhad an illegal signature.  So what we should have done, and what this\npatch does, is to decouple the extra-dummy-arguments behavior from\nordered-set aggregates and make it generally available for all aggregate\ndeclarations.  We have to put this into 9.4 rather than waiting till\nlater because it slightly alters the rules for declaring ordered-set\naggregates.\n\nThe patch turned out a bit bigger than I'd hoped because it proved\nnecessary to record the extra-arguments option in a new pg_aggregate\ncolumn.  I'd thought we could just look at the final function's pronargs\nat runtime, but that didn't work well for variadic final functions.\nIt's probably just as well though, because it simplifies life for pg_dump\nto record the option explicitly.\n\nWhile at it, fix array_agg() to have a valid final-function signature,\nand add an opr_sanity test to notice future deviations from polymorphic\nconsistency.  I also marked the percentile_cont() aggregates as not\nneeding extra arguments, since they don't.","Tom Lane",false],["a0f9358149b78c62871a0b7d3c167b78f9b2c77e","ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","Fix incorrect pg_proc.proallargtypes entries for two built-in functions.\n\npg_sequence_parameters() and pg_identify_object() have had incorrect\nproallargtypes entries since 9.1 and 9.3 respectively.  This was mostly\nmasked by the correct information in proargtypes, but a few operations\nsuch as pg_get_function_arguments() (and thus psql's \\df display) would\nshow the wrong data types for these functions' input parameters.\n\nIn HEAD, fix the wrong info, bump catversion, and add an opr_sanity\nregression test to catch future mistakes of this sort.\n\nIn the back branches, just fix the wrong info so that installations\ninitdb'd with future minor releases will have the right data.  We\ncan't force an initdb, and it doesn't seem like a good idea to add\na regression test that will fail on existing installations.\n\nAndres Freund","Tom Lane",false],["b2c9b161b8ae36dd9972e77297274afb9a675782","9f4ca770b638615ac5c3e0d2da16b77c80c2f2c6@hagander.net","Properly build pg_recvlogical in the msvc build system\n\nMichael Paquier","Magnus Hagander",false],["d19bd29f07aef9e508ff047d128a4046cc8bc1e2","ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","Reset pg_stat_activity.xact_start during PREPARE TRANSACTION.\n\nOnce we've completed a PREPARE, our session is not running a transaction,\nso its entry in pg_stat_activity should show xact_start as null, rather\nthan leaving the value as the start time of the now-prepared transaction.\n\nI think possibly this oversight was triggered by faulty extrapolation\nfrom the adjacent comment that says PrepareTransaction should not call\nAtEOXact_PgStat, so tweak the wording of that comment.\n\nNoted by Andres Freund while considering bug #10123 from Maxim Boguk,\nalthough this error doesn't seem to explain that report.\n\nBack-patch to all active branches.","Tom Lane",false],["1a917ae8610d44985fd2027da0cfe60ccece9104","3c84f0de6f8a0f296d36cdd9f57fa166641c96b1@alvh.no-ip.org","Fix race when updating a tuple concurrently locked by another process\n\nIf a tuple is locked, and this lock is later upgraded either to an\nupdate or to a stronger lock, and in the meantime some other process\ntries to lock, update or delete the same tuple, it (the tuple) could end\nup being updated twice, or having conflicting locks held.\n\nThe reason for this is that the second updater checks for a change in\nXmax value, or in the HEAP_XMAX_IS_MULTI infomask bit, after noticing\nthe first lock; and if there's a change, it restarts and re-evaluates\nits ability to update the tuple.  But it neglected to check for changes\nin lock strength or in lock-vs-update status when those two properties\nstayed the same.  This would lead it to take the wrong decision and\ncontinue with its own update, when in reality it shouldn't do so but\ninstead restart from the top.\n\nThis could lead to either an assertion failure much later (when a\nmultixact containing multiple updates is detected), or duplicate copies\nof tuples.\n\nTo fix, make sure to compare the other relevant infomask bits alongside\nthe Xmax value and HEAP_XMAX_IS_MULTI bit, and restart from the top if\nnecessary.\n\nAlso, in the belt-and-suspenders spirit, add a check to\nMultiXactCreateFromMembers that a multixact being created does not have\ntwo or more members that are claimed to be updates.  This should protect\nagainst other bugs that might cause similar bogus situations.\n\nBackpatch to 9.3, where the possibility of multixacts containing updates\nwas introduced.  (In prior versions it was possible to have the tuple\nlock upgraded from shared to exclusive, and an update would not restart\nfrom the top; yet we're protected against a bug there because there's\nalways a sleep to wait for the locking transaction to complete before\ncontinuing to do anything.  Really, the fact that tuple locks always\nconflicted with concurrent updates is what protected against bugs here.)\n\nPer report from Andrew Dunstan and Josh Berkus in thread at\nhttp://www.postgresql.org/message-id/534C8B33.9050807@pgexperts.com\n\nBug analysis by Andres Freund.","Alvaro Herrera",false],["799d9a31d0dde0cde7823a2c01b82a106f6ca176","b43aa4da7d49446458a27682d03373956825fb53@gmail.com","merge master","Fabrízio de Royes Mello",true]],"size":7,"ref":"refs/heads/create_sequence_if_not_exists","head":"799d9a31d0dde0cde7823a2c01b82a106f6ca176"}