{"push_id":3139595200,"size":15,"distinct_size":6,"ref":"refs/heads/partition_tablespace","head":"96e7172b9f048b6de9879606603ef5630dd28be4","before":"f7a645a9a504f09e0277f8e0ef45e409c36af014","commits":[{"sha":"1db439ad49255d8fb0371cc7166cdc33f6b3fdf3","author":{"name":"Noah Misch","email":"1db01d43e08596f43a65fb393d969b98ee5b4dc6@leadboat.com"},"message":"Raise some timeouts to 180s, in test code.\n\nSlow runs of buildfarm members chipmunk, hornet and mandrill saw the\nshorter timeouts expire.  The 180s timeout in poll_query_until has been\ntrouble-free since 2a0f89cd717ce6d49cdc47850577823682167e87 introduced\nit two years ago, so use 180s more widely.  Back-patch to 9.6, where the\nfirst of these timeouts was introduced.\n\nReviewed by Michael Paquier.\n\nDiscussion: https://postgr.es/m/20181209001601.GC2973271@rfd.leadboat.com","distinct":false,"url":"https://api.github.com/repos/michaelpq/postgres/commits/1db439ad49255d8fb0371cc7166cdc33f6b3fdf3"},{"sha":"d65ddb2b5674cd6cf444c4825270a12b968055ac","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Doc: improve documentation about ALTER LARGE OBJECT requirements.\n\nUnlike other ALTER ref pages, this one neglected to mention that\nALTER OWNER requires being a member of the new owning role.\nPer bug #15546 from Stefan Kadow.\n\nDiscussion: https://postgr.es/m/15546-0558c75fd2025e7c@postgresql.org","distinct":false,"url":"https://api.github.com/repos/michaelpq/postgres/commits/d65ddb2b5674cd6cf444c4825270a12b968055ac"},{"sha":"7a28e9aa0fd966ed374d244896e397148336720a","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Fix test_rls_hooks to assign expression collations properly.\n\nThis module overlooked this necessary fixup step on the results of\ntransformWhereClause().  It accidentally worked anyway, because the\nconstructed expression involved type \"name\" which is not collatable,\nbut it fell over while I was experimenting with changing \"name\" to\nbe collatable.\n\nBack-patch, not because there's any live bug here in back branches,\nbut because somebody might use this code as a model for some real\napplication and then not understand why it doesn't work.","distinct":false,"url":"https://api.github.com/repos/michaelpq/postgres/commits/7a28e9aa0fd966ed374d244896e397148336720a"},{"sha":"cc53123bcc9d8786acae2885c3a0897b7be34a02","author":{"name":"Michael Paquier","email":"17b9e1c64588c7fa6419b4d29dc1f4426279ba01@paquier.xyz"},"message":"Tweak pg_partition_tree for undefined relations and unsupported relkinds\n\nThis fixes a crash which happened when calling the function directly\nwith a relation OID referring to a non-existing object, and changes the\nbehavior so as NULL is returned for unsupported relkinds instead of\ngenerating an error.  This puts the new function in line with many other\nsystem functions, and eases actions like full scans of pg_class.\n\nAuthor: Michael Paquier\nReviewed-by: Amit Langote, Stephen Frost\nDiscussion: https://postgr.es/m/20181207010406.GO2407@paquier.xyz","distinct":false,"url":"https://api.github.com/repos/michaelpq/postgres/commits/cc53123bcc9d8786acae2885c3a0897b7be34a02"},{"sha":"0f7ec8d9c3aeb8964d3539561e5c8d4caef42bf6","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Repair bogus handling of multi-assignment Params in upper plan levels.\n\nOur support for multiple-set-clauses in UPDATE assumes that the Params\nreferencing a MULTIEXPR_SUBLINK SubPlan will appear before that SubPlan\nin the targetlist of the plan node that calculates the updated row.\n(Yeah, it's a hack...)  In some PG branches it's possible that a Result\nnode gets inserted between the primary calculation of the update tlist\nand the ModifyTable node.  setrefs.c did the wrong thing in this case\nand left the upper-level Params as Params, causing a crash at runtime.\nWhat it should do is replace them with \"outer\" Vars referencing the child\nplan node's output.  That's a result of careless ordering of operations\nin fix_upper_expr_mutator, so we can fix it just by reordering the code.\n\nFix fix_join_expr_mutator similarly for consistency, even though join\nnodes could never appear in such a context.  (In general, it seems\nlikely to be a bit cheaper to use Vars than Params in such situations\nanyway, so this patch might offer a tiny performance improvement.)\n\nThe hazard extends back to 9.5 where the MULTIEXPR_SUBLINK stuff\nwas introduced, so back-patch that far.  However, this may be a live\nbug only in 9.6.x and 10.x, as the other branches don't seem to want\nto calculate the final tlist below the Result node.  (That plan shape\nchange between branches might be a mini-bug in itself, but I'm not\nreally interested in digging into the reasons for that right now.\nStill, add a regression test memorializing what we expect there,\nso we'll notice if it changes again.)\n\nPer bug report from Eduards Bezverhijs.\n\nDiscussion: https://postgr.es/m/b6cd572a-3e44-8785-75e9-c512a5a17a73@tieto.com","distinct":false,"url":"https://api.github.com/repos/michaelpq/postgres/commits/0f7ec8d9c3aeb8964d3539561e5c8d4caef42bf6"},{"sha":"77d4d88afbaa37773d15578d89881fa175ec38e8","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Repair bogus EPQ plans generated for postgres_fdw foreign joins.\n\npostgres_fdw's postgresGetForeignPlan() assumes without checking that the\nouter_plan it's given for a join relation must have a NestLoop, MergeJoin,\nor HashJoin node at the top.  That's been wrong at least since commit\n4bbf6edfb (which could cause insertion of a Sort node on top) and it seems\nlike a pretty unsafe thing to Just Assume even without that.\n\nThrough blind good fortune, this doesn't seem to have any worse\nconsequences today than strange EXPLAIN output, but it's clearly trouble\nwaiting to happen.\n\nTo fix, test the node type explicitly before touching Join-specific\nfields, and avoid jamming the new tlist into a node type that can't\ndo projection.  Export a new support function from createplan.c\nto avoid building low-level knowledge about the latter into FDWs.\n\nBack-patch to 9.6 where the faulty coding was added.  Note that the\nassociated regression test cases don't show any changes before v11,\napparently because the tests back-patched with 4bbf6edfb don't actually\nexercise the problem case before then (there's no top-level Sort\nin those plans).\n\nDiscussion: https://postgr.es/m/8946.1544644803@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/michaelpq/postgres/commits/77d4d88afbaa37773d15578d89881fa175ec38e8"},{"sha":"fd83c83d0943a6717dbe521efa10da9dce94e4cd","author":{"name":"Alexander Korotkov","email":"1c137998207470ad0f56303c4fc305487ec0232f@postgresql.org"},"message":"Fix deadlock in GIN vacuum introduced by 218f51584d5\n\nBefore 218f51584d5 if posting tree page is about to be deleted, then the whole\nposting tree is locked by LockBufferForCleanup() on root preventing all the\nconcurrent inserts.  218f51584d5 reduced locking to the subtree containing\npage to be deleted.  However, due to concurrent parent split, inserter doesn't\nalways holds pins on all the pages constituting path from root to the target\nleaf page.  That could cause a deadlock between GIN vacuum process and GIN\ninserter.  And we didn't find non-invasive way to fix this.\n\nThis commit reverts VACUUM behavior to lock the whole posting tree before\ndelete any page.  However, we keep another useful change by 218f51584d5: the\ntree is locked only if there are pages to be deleted.\n\nReported-by: Chen Huajun\nDiagnosed-by: Chen Huajun, Andrey Borodin, Peter Geoghegan\nDiscussion: https://postgr.es/m/31a702a.14dd.166c1366ac1.Coremail.chjischj%40163.com\nAuthor: Alexander Korotkov, based on ideas from Andrey Borodin and Peter Geoghegan\nReviewed-by: Andrey Borodin\nBackpatch-through: 10","distinct":false,"url":"https://api.github.com/repos/michaelpq/postgres/commits/fd83c83d0943a6717dbe521efa10da9dce94e4cd"},{"sha":"c6ade7a8cd3135af0c5d29abf39a6a83b9f6a66a","author":{"name":"Alexander Korotkov","email":"1c137998207470ad0f56303c4fc305487ec0232f@postgresql.org"},"message":"Prevent deadlock in ginRedoDeletePage()\n\nOn standby ginRedoDeletePage() can work concurrently with read-only queries.\nThose queries can traverse posting tree in two ways.\n1) Using rightlinks by ginStepRight(), which locks the next page before\n   unlocking its left sibling.\n2) Using downlinks by ginFindLeafPage(), which locks at most one page at time.\n\nOriginal lock order was: page, parent, left sibling.  That lock order can\ndeadlock with ginStepRight().  In order to prevent deadlock this commit changes\nlock order to: left sibling, page, parent.  Note, that position of parent in\nlocking order seems insignificant, because we only lock one page at time while\ntraversing downlinks.\n\nReported-by: Chen Huajun\nDiagnosed-by: Chen Huajun, Peter Geoghegan, Andrey Borodin\nDiscussion: https://postgr.es/m/31a702a.14dd.166c1366ac1.Coremail.chjischj%40163.com\nAuthor: Alexander Korotkov\nBackpatch-through: 9.4","distinct":false,"url":"https://api.github.com/repos/michaelpq/postgres/commits/c6ade7a8cd3135af0c5d29abf39a6a83b9f6a66a"},{"sha":"52ac6cd2d0cd70e01291e0ac4ee6d068b69bc478","author":{"name":"Alexander Korotkov","email":"1c137998207470ad0f56303c4fc305487ec0232f@postgresql.org"},"message":"Prevent GIN deleted pages from being reclaimed too early\n\nWhen GIN vacuum deletes a posting tree page, it assumes that no concurrent\nsearchers can access it, thanks to ginStepRight() locking two pages at once.\nHowever, since 9.4 searches can skip parts of posting trees descending from the\nroot.  That leads to the risk that page is deleted and reclaimed before\nconcurrent search can access it.\n\nThis commit prevents the risk of above by waiting for every transaction, which\nmight wait to reference this page, to finish.  Due to binary compatibility\nwe can't change GinPageOpaqueData to store corresponding transaction id.\nInstead we reuse page header pd_prune_xid field, which is unused in index pages.\n\nDiscussion: https://postgr.es/m/31a702a.14dd.166c1366ac1.Coremail.chjischj%40163.com\nAuthor: Andrey Borodin, Alexander Korotkov\nReviewed-by: Alexander Korotkov\nBackpatch-through: 9.4","distinct":false,"url":"https://api.github.com/repos/michaelpq/postgres/commits/52ac6cd2d0cd70e01291e0ac4ee6d068b69bc478"},{"sha":"04fe805a1734eccd8dcdd34c8cc0ddcb62c7240c","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Drop no-op CoerceToDomain nodes from expressions at planning time.\n\nIf a domain has no constraints, then CoerceToDomain doesn't really do\nanything and can be simplified to a RelabelType.  This not only\neliminates cycles at execution, but allows the planner to optimize better\n(for instance, match the coerced expression to an index on the underlying\ncolumn).  However, we do have to support invalidating the plan later if\na constraint gets added to the domain.  That's comparable to the case of\na change to a SQL function that had been inlined into a plan, so all the\nnecessary logic already exists for plans depending on functions.  We\nneed only duplicate or share that logic for domains.\n\nALTER DOMAIN ADD/DROP CONSTRAINT need to be taught to send out sinval\nmessages for the domain's pg_type entry, since those operations don't\nupdate that row.  (ALTER DOMAIN SET/DROP NOT NULL do update that row,\nso no code change is needed for them.)\n\nTesting this revealed what's really a pre-existing bug in plpgsql:\nit caches the SQL-expression-tree expansion of type coercions and\nhad no provision for invalidating entries in that cache.  Up to now\nthat was only a problem if such an expression had inlined a SQL\nfunction that got changed, which is unlikely though not impossible.\nBut failing to track changes of domain constraints breaks an existing\nregression test case and would likely cause practical problems too.\n\nWe could fix that locally in plpgsql, but what seems like a better\nidea is to build some generic infrastructure in plancache.c to store\nstandalone expressions and track invalidation events for them.\n(It's tempting to wonder whether plpgsql's \"simple expression\" stuff\ncould use this code with lower overhead than its current use of the\nheavyweight plancache APIs.  But I've left that idea for later.)\n\nOther stuff fixed in passing:\n\n* Allow estimate_expression_value() to drop CoerceToDomain\nunconditionally, effectively assuming that the coercion will succeed.\nThis will improve planner selectivity estimates for cases involving\nestimatable expressions that are coerced to domains.  We could have\ndone this independently of everything else here, but there wasn't\npreviously any need for eval_const_expressions_mutator to know about\nCoerceToDomain at all.\n\n* Use a dlist for plancache.c's list of cached plans, rather than a\nmanually threaded singly-linked list.  That eliminates a potential\nperformance problem in DropCachedPlan.\n\n* Fix a couple of inconsistencies in typecmds.c about whether\noperations on domains drop RowExclusiveLock on pg_type.  Our common\npractice is that DDL operations do drop catalog locks, so standardize\non that choice.\n\nDiscussion: https://postgr.es/m/19958.1544122124@sss.pgh.pa.us","distinct":true,"url":"https://api.github.com/repos/michaelpq/postgres/commits/04fe805a1734eccd8dcdd34c8cc0ddcb62c7240c"},{"sha":"84d514887f9ca673ae688d00f8b544e70f1ab270","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Fix bogus logic for skipping unnecessary partcollation dependencies.\n\nThe idea here is to not call recordDependencyOn for the default collation,\nsince we know that's pinned.  But what the code actually did was to record\nthe partition key's dependency on the opclass twice, instead.\n\nEvidently introduced by sloppy coding in commit 2186b608b.  Back-patch\nto v10 where that came in.","distinct":true,"url":"https://api.github.com/repos/michaelpq/postgres/commits/84d514887f9ca673ae688d00f8b544e70f1ab270"},{"sha":"09568ec3d31bbd4854b857e8d23c197ad5b25c77","author":{"name":"Andres Freund","email":"883768b6dd2c42aea0031b24be8a2da40fef4b64@anarazel.de"},"message":"Create a separate oid range for oids assigned by genbki.pl.\n\nThe changes I made in 578b229718e assigned oids below\nFirstBootstrapObjectId to objects in include/catalog/*.dat files that\ndid not have an oid assigned, starting at the max oid explicitly\nassigned.  Tom criticized that for mainly two reasons:\n1) It's not clear which values are manually and which explicitly\n   assigned.\n2) The space below FirstBootstrapObjectId gets pretty crowded, and\n   some PostgreSQL forks have used oids >= 9000 for their own objects,\n   to avoid conflicting.\n\nThus create a new range for objects not assigned explicit oids, but\nassigned by genbki.pl. For now 1-9999 is for explicitly assigned oids,\nFirstGenbkiObjectId (10000) to FirstBootstrapObjectId (1200) -1 is for\ngenbki.pl assigned oids, and < FirstNormalObjectId (16384) is for oids\nassigned during bootstrap.  It's possible that we'll have to adjust\nthese boundaries, but there's some headroom for now.\n\nAdd a note suggesting that oids in forks should be assigned in the\n9000-9999 range.\n\nCatversion bump for obvious reasons.\n\nPer complaint from Tom Lane.\n\nAuthor: Andres Freund\nDiscussion: https://postgr.es/m/16845.1544393682@sss.pgh.pa.us","distinct":true,"url":"https://api.github.com/repos/michaelpq/postgres/commits/09568ec3d31bbd4854b857e8d23c197ad5b25c77"},{"sha":"8fb569e978af3995f0dd6b0033758ec571aab0c1","author":{"name":"Michael Paquier","email":"17b9e1c64588c7fa6419b4d29dc1f4426279ba01@paquier.xyz"},"message":"Introduce new extended routines for FDW and foreign server lookups\n\nThe cache lookup routines for foreign-data wrappers and foreign servers\nare extended with an extra argument to handle a set of flags.  The only\nvalue which can be used now is to indicate if a missing object should\nresult in an error or not, and are designed to be extensible on need.\nThose new routines are added into the existing set of user-visible\nFDW APIs and documented in consequence.  They will be used for future\npatches to improve the SQL interface for object addresses.\n\nAuthor: Michael Paquier\nReviewed-by: Álvaro Herrera\nDiscussion: https://postgr.es/m/CAB7nPqSZxrSmdHK-rny7z8mi=EAFXJ5J-0RbzDw6aus=wB5azQ@mail.gmail.com","distinct":true,"url":"https://api.github.com/repos/michaelpq/postgres/commits/8fb569e978af3995f0dd6b0033758ec571aab0c1"},{"sha":"5e09280057a4c3f5db297348ea3e044c9c5f4ef8","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Make pg_statistic and related code account more honestly for collations.\n\nWhen we first put in collations support, we basically punted on teaching\npg_statistic, ANALYZE, and the planner selectivity functions about that.\nThey've just used DEFAULT_COLLATION_OID independently of the actual\ncollation of the data.  It's time to improve that, so:\n\n* Add columns to pg_statistic that record the specific collation associated\nwith each statistics slot.\n\n* Teach ANALYZE to use the column's actual collation when comparing values\nfor statistical purposes, and record this in the appropriate slot.  (Note\nthat type-specific typanalyze functions are now expected to fill\nstats->stacoll with the appropriate collation, too.)\n\n* Teach assorted selectivity functions to use the actual collation of\nthe stats they are looking at, instead of just assuming it's\nDEFAULT_COLLATION_OID.\n\nThis should give noticeably better results in selectivity estimates for\ncolumns with nondefault collations, at least for query clauses that use\nthat same collation (which would be the default behavior in most cases).\nIt's still true that comparisons with explicit COLLATE clauses different\nfrom the stored data's collation won't be well-estimated, but that's no\nworse than before.  Also, this patch does make the first step towards\ndoing better with that, which is that it's now theoretically possible to\ncollect stats for a collation other than the column's own collation.\n\nPatch by me; thanks to Peter Eisentraut for review.\n\nDiscussion: https://postgr.es/m/14706.1544630227@sss.pgh.pa.us","distinct":true,"url":"https://api.github.com/repos/michaelpq/postgres/commits/5e09280057a4c3f5db297348ea3e044c9c5f4ef8"},{"sha":"96e7172b9f048b6de9879606603ef5630dd28be4","author":{"name":"Michael Paquier","email":"17b9e1c64588c7fa6419b4d29dc1f4426279ba01@paquier.xyz"},"message":"Modify patch","distinct":true,"url":"https://api.github.com/repos/michaelpq/postgres/commits/96e7172b9f048b6de9879606603ef5630dd28be4"}]}
{"actor":{"display_login":"michaelpq"}}