{"push_id":2958187699,"size":6,"distinct_size":1,"ref":"refs/heads/commitfest/20/1085","head":"6ae3501f31b269aa0fb84ae5964d811cf8906315","before":"5644cc87e23eef0178586ed760226b5c78f39bb2","commits":[{"sha":"8f850f2cad2df69a14fd1ad1b360cf004f17e8db","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Doc: still further copy-editing for v11 release notes.\n\nJustin Pryzby and myself.\n\nDiscussion: https://postgr.es/m/20181006134249.GD871@telsasoft.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/8f850f2cad2df69a14fd1ad1b360cf004f17e8db"},{"sha":"1df21ddb19c6e764fc9378c900515a5d642ad820","author":{"name":"Michael Paquier","email":"17b9e1c64588c7fa6419b4d29dc1f4426279ba01@paquier.xyz"},"message":"Avoid duplicate XIDs at recovery when building initial snapshot\n\nOn a primary, sets of XLOG_RUNNING_XACTS records are generated on a\nperiodic basis to allow recovery to build the initial state of\ntransactions for a hot standby.  The set of transaction IDs is created\nby scanning all the entries in ProcArray.  However it happens that its\nlogic never counted on the fact that two-phase transactions finishing to\nprepare can put ProcArray in a state where there are two entries with\nthe same transaction ID, one for the initial transaction which gets\ncleared when prepare finishes, and a second, dummy, entry to track that\nthe transaction is still running after prepare finishes.  This way\nensures a continuous presence of the transaction so as callers of for\nexample TransactionIdIsInProgress() are always able to see it as alive.\n\nSo, if a XLOG_RUNNING_XACTS takes a standby snapshot while a two-phase\ntransaction finishes to prepare, the record can finish with duplicated\nXIDs, which is a state expected by design.  If this record gets applied\non a standby to initial its recovery state, then it would simply fail,\nso the odds of facing this failure are very low in practice.  It would\nbe tempting to change the generation of XLOG_RUNNING_XACTS so as\nduplicates are removed on the source, but this requires to hold on\nProcArrayLock for longer and this would impact all workloads,\nparticularly those using heavily two-phase transactions.\n\nXLOG_RUNNING_XACTS is also actually used only to initialize the standby\nstate at recovery, so instead the solution is taken to discard\nduplicates when applying the initial snapshot.\n\nDiagnosed-by: Konstantin Knizhnik\nAuthor: Michael Paquier\nDiscussion: https://postgr.es/m/0c96b653-4696-d4b4-6b5d-78143175d113@postgrespro.ru\nBackpatch-through: 9.3","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/1df21ddb19c6e764fc9378c900515a5d642ad820"},{"sha":"e9f42d529f990f94e1b7bdcec4a1111465c85326","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Clean up/tighten up coercibility checks in opr_sanity regression test.\n\nWith the removal of the old abstime type, there are no longer any cases\nin this test where we need to use the weaker castcontext-ignoring form\nof binary coercibility check.  (The other major source of such headaches,\napparently-incompatible hash functions, is now hashvalidate()'s problem\nnot this test script's problem.)  Hence, just use binary_coercible()\neverywhere, and remove the comments explaining why we don't do so ---\nwhich were broken anyway by cda6a8d01.\n\nI left physically_coercible() in place but renamed it to better\nmatch what it's actually testing, and added some comments.\n\nAlso, in test queries that have an assumption about the maximum number\nof function arguments they need to handle, add a clause to make them fail\nif someday there's a relevant function with more arguments.  Otherwise\nwe're likely not to notice that we need to extend the queries.\n\nDiscussion: https://postgr.es/m/27637.1539388060@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/e9f42d529f990f94e1b7bdcec4a1111465c85326"},{"sha":"7d4a10e260083bc571ea05592884084eabcc7afa","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Use PlaceHolderVars within the quals of a FULL JOIN.\n\nThis prevents failures in cases where we pull up a constant or var-free\nexpression from a subquery and put it into a full join's qual.  That can\nresult in not recognizing the qual as containing a mergejoin-able or\nhashjoin-able condition.  A PHV prevents the problem because it is still\nrecognized as belonging to the side of the join the subquery is in.\n\nI'm not very sure about the net effect of this change on plan quality.\nIn \"typical\" cases where the join keys are Vars, nothing changes.\nIn an affected case, the PHV-wrapped expression is less likely to be seen\nas equal to PHV-less instances below the join, but more likely to be seen\nas equal to similar expressions above the join, so it may end up being a\nwash.  In the one existing case where there's any visible change in a\nregression-test plan, it amounts to referencing a lower computation of a\nCOALESCE result instead of recomputing it, which seems like a win.\n\nGiven my uncertainty about that and the lack of field complaints,\nno back-patch, even though this is a very ancient problem.\n\nDiscussion: https://postgr.es/m/32090.1539378124@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/7d4a10e260083bc571ea05592884084eabcc7afa"},{"sha":"b403ea43e40aae3ebb03cf3844cf84b43ab34b8a","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Make some subquery-using test cases a bit more robust.\n\nThese test cases could be adversely affected by an upcoming change\nto allow pullup of FROM-less subqueries.  Tweak them to ensure that\nthey'll continue to test what they did before.\n\nDiscussion: https://postgr.es/m/5395.1539275668@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/b403ea43e40aae3ebb03cf3844cf84b43ab34b8a"},{"sha":"6ae3501f31b269aa0fb84ae5964d811cf8906315","author":{"name":"Commitfest Bot","email":"b9e638e07cc2e2abf56c9c0cad7954f2e3bc1641@cputube.org"},"message":"[CF 20/1085] XML XPath default namespace support\n\nThis commit was automatically generated by cfbot at commitfest.cputube.org.\nIt is based on patches submitted to the PostgreSQL mailing lists and\nregistered in the PostgreSQL Commitfest application.\n\nThis branch will be overwritten each time a new patch version is posted to\nthe email thread, and also periodically to check for bitrot caused by changes\non the master branch.\n\nCommitfest entry: https://commitfest.postgresql.org/20/1085\nPatch(es): https://www.postgresql.org/message-id/CAFj8pRAeDNoqOVZG9-5nFxev-ZpTeOP8qsxZN-i4dQ48E67NaQ@mail.gmail.com\nAuthor(s): Pavel Stehule","distinct":true,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/6ae3501f31b269aa0fb84ae5964d811cf8906315"}]}
{"actor":{"display_login":"postgresql-cfbot"}}