{"push_id":3824121006,"size":12,"distinct_size":1,"ref":"refs/heads/commitfest/23/2151","head":"4a4f12b2e57e375a318cc2b5089d1c31b986f380","before":"a8708cb0bfdf1c3f79e7c623783b15dbcbecf4d3","commits":[{"sha":"e3899ffd8beafdaaa037b503163a9f572e9fc729","author":{"name":"Peter Geoghegan","email":"96dd8d96902e9c5af3b96b1eaa9c80cbc615d290@bowt.ie"},"message":"Fix pathological nbtree split point choice issue.\n\nSpecific ever-decreasing insertion patterns could cause successive\nunbalanced nbtree page splits.  Problem cases involve a large group of\nduplicates to the left, and ever-decreasing insertions to the right.\n\nTo fix, detect the situation by considering the newitem offset before\nperforming a split using nbtsplitloc.c's \"many duplicates\" strategy.  If\nthe new item was inserted just to the right of our provisional \"many\nduplicates\" split point, infer ever-decreasing insertions and fall back\non a 50:50 (space delta optimal) split.  This seems to barely affect\ncases that already had acceptable space utilization.\n\nAn alternative fix also seems possible.  Instead of changing\nnbtsplitloc.c split choice logic, we could instead teach _bt_truncate()\nto generate a new value for new high keys by interpolating from the\nlastleft and firstright key values.  That would certainly be a more\nelegant fix, but it isn't suitable for backpatching.\n\nDiscussion: https://postgr.es/m/CAH2-WznCNvhZpxa__GqAa1fgQ9uYdVc=_apArkW2nc-K3O7_NA@mail.gmail.com\nBackpatch: 12-, where the nbtree page split enhancements were introduced.","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/e3899ffd8beafdaaa037b503163a9f572e9fc729"},{"sha":"bfdbac2ab3ef1a12a7de231552b128ed83ad00bb","author":{"name":"Peter Geoghegan","email":"96dd8d96902e9c5af3b96b1eaa9c80cbc615d290@bowt.ie"},"message":"Correct nbtsplitloc.c comment.\n\nThe logic just added by commit e3899ffd falls back on a 50:50 page split\nin the event of a new item that's just to the right of our provisional\n\"many duplicates\" split point.  Fix a comment that incorrectly claimed\nthat the new item had to be just to the left of our provisional split\npoint.\n\nBackpatch: 12-, just like commit e3899ffd.","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/bfdbac2ab3ef1a12a7de231552b128ed83ad00bb"},{"sha":"ce8f946764005e1bde5a538542205e55f81bb6cc","author":{"name":"Thomas Munro","email":"1ff054ef0838bf068a4b7c40eef026e560a37025@postgresql.org"},"message":"Report the time taken by pgbench initialization steps.\n\nAuthor: Fabien Coelho\nReviewed-by: Ibrar Ahmed\nDiscussion: https://postgr.es/m/alpine.DEB.2.21.1904061810510.3678%40lancre","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/ce8f946764005e1bde5a538542205e55f81bb6cc"},{"sha":"5823677acc567d7790cc68972de12f6718913d7d","author":{"name":"Thomas Munro","email":"1ff054ef0838bf068a4b7c40eef026e560a37025@postgresql.org"},"message":"Provide pgbench --show-script to dump built-in scripts.\n\nAuthor: Fabien Coelho\nReviewed-by: Ibrar Ahmed\nDiscussion: https://postgr.es/m/alpine.DEB.2.21.1904081737390.5867%40lancre","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/5823677acc567d7790cc68972de12f6718913d7d"},{"sha":"c6bce6ebb668c7da03d01244d34cac0335561103","author":{"name":"Bruce Momjian","email":"9ae9c44b775ee9b29f4f502415e02e61a9b1a6a0@momjian.us"},"message":"doc:  mention pg_reload_conf() for reloading the config file\n\nReported-by: Ian Barwick\n\nDiscussion: https://postgr.es/m/538950ec-b86a-1650-6078-beb7091c09c2@2ndquadrant.com\n\nBackpatch-through: 9.4","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/c6bce6ebb668c7da03d01244d34cac0335561103"},{"sha":"4c3d05d875dd173a81a995c6e14d69496b467eec","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Remove dead code.\n\nThese memory context switches are useless in the wake of commit\n1cff1b95a.  Noted by Jesper Pedersen.\n\nDiscussion: https://postgr.es/m/f078ce63-9e04-0f3e-d200-d7ee66279abe@redhat.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/4c3d05d875dd173a81a995c6e14d69496b467eec"},{"sha":"0896ae561b6c799d45cb61d8a3b18fbb442130a7","author":{"name":"Michael Paquier","email":"17b9e1c64588c7fa6419b4d29dc1f4426279ba01@paquier.xyz"},"message":"Fix inconsistencies and typos in the tree\n\nThis is numbered take 7, and addresses a set of issues around:\n- Fixes for typos and incorrect reference names.\n- Removal of unneeded comments.\n- Removal of unreferenced functions and structures.\n- Fixes regarding variable name consistency.\n\nAuthor: Alexander Lakhin\nDiscussion: https://postgr.es/m/10bfd4ac-3e7c-40ab-2b2e-355ed15495e8@gmail.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/0896ae561b6c799d45cb61d8a3b18fbb442130a7"},{"sha":"569ed7f48312c70ed4a79daec1d7688fda4e74ac","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Redesign the API for list sorting (list_qsort becomes list_sort).\n\nIn the wake of commit 1cff1b95a, the obvious way to sort a List\nis to apply qsort() directly to the array of ListCells.  list_qsort\nwas building an intermediate array of pointers-to-ListCells, which\nwe no longer need, but getting rid of it forces an API change:\nthe comparator functions need to do one less level of indirection.\n\nSince we're having to touch the callers anyway, let's do two additional\nchanges: sort the given list in-place rather than making a copy (as\nnone of the existing callers have any use for the copying behavior),\nand rename list_qsort to list_sort.  It was argued that the old name\nexposes more about the implementation than it should, which I find\npretty questionable, but a better reason to rename it is to be sure\nwe get the attention of any external callers about the need to fix\ntheir comparator functions.\n\nWhile we're at it, change four existing callers of qsort() to use\nlist_sort instead; previously, they all had local reinventions\nof list_qsort, ie build-an-array-from-a-List-and-qsort-it.\n(There are some other places where changing to list_sort perhaps\nwould be worthwhile, but they're less obviously wins.)\n\nDiscussion: https://postgr.es/m/29361.1563220190@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/569ed7f48312c70ed4a79daec1d7688fda4e74ac"},{"sha":"2f5b8eb5a28b4e6de9d20cc7d2c6028c6c7a8aa8","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Clean up some ad-hoc code for sorting and de-duplicating Lists.\n\nheap.c and relcache.c contained nearly identical copies of logic\nto insert OIDs into an OID list while preserving the list's OID\nordering (and rejecting duplicates, in one case but not the other).\n\nThe comments argue that this is faster than qsort for small numbers\nof OIDs, which is at best unproven, and seems even less likely to be\ntrue now that lappend_cell_oid has to move data around.  In any case\nit's ugly and hard-to-follow code, and if we do have a lot of OIDs\nto consider, it's O(N^2).\n\nHence, replace with simply lappend'ing OIDs to a List, then list_sort\nthe completed List, then remove adjacent duplicates if necessary.\nThis is demonstrably O(N log N) and it's much simpler for the\ncallers.  It's possible that this would be somewhat inefficient\nif there were a very large number of duplicates, but that seems\nunlikely in the existing usage.\n\nThis adds list_deduplicate_oid and list_oid_cmp infrastructure\nto list.c.  I didn't bother with equivalent functionality for\ninteger or pointer Lists, but such could always be added later\nif we find a use for it.\n\nDiscussion: https://postgr.es/m/26193.1563228600@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/2f5b8eb5a28b4e6de9d20cc7d2c6028c6c7a8aa8"},{"sha":"c245776906b065fcd59831a25c3b24ad3ddcd849","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Remove lappend_cell...() family of List functions.\n\nIt seems worth getting rid of these functions because they require the\ncaller to retain a ListCell pointer into a List that it's modifying,\nwhich is a dangerous practice with the new List implementation.\n(The only other List-modifying function that takes a ListCell pointer\nas input is list_delete_cell, which nowadays is preferentially used\nvia the constrained API foreach_delete_current.)\n\nThere was only one remaining caller of these functions after commit\n2f5b8eb5a, and that was some fairly ugly GEQO code that can be much\nmore clearly expressed using a list-index variable and list_insert_nth.\nHence, rewrite that code, and remove the functions.\n\nDiscussion: https://postgr.es/m/26193.1563228600@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/c245776906b065fcd59831a25c3b24ad3ddcd849"},{"sha":"3093eb2b83645a083a47ea62769ffd89e31f3664","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Fix thinko in construction of old_conpfeqop list.\n\nThis should lappend the OIDs, not lcons them; the existing code produced\na list in reversed order.  This is harmless for single-key FKs or FKs\nwhere all the key columns are of the same type, which probably explains\nhow it went unnoticed.  But if those conditions are not met,\nATAddForeignKeyConstraint would make the wrong decision about whether an\nexisting FK needs to be revalidated.  I think it would almost always err\nin the safe direction by revalidating a constraint that didn't need it.\nYou could imagine scenarios where the pfeqop check was fooled by\nswapping the types of two FK columns in one ALTER TABLE, but that case\nwould probably be rejected by other tests, so it might be impossible to\nget to the worst-case scenario where an FK should be revalidated and\nisn't.  (And even then, it's likely to be fine, unless there are weird\ninconsistencies in the equality behavior of the replacement types.)\nHowever, this is a performance bug at least.\n\nNoted while poking around to see whether lcons calls could be converted\nto lappend.\n\nThis bug is old, dating to commit cb3a7c2b9, so back-patch to all\nsupported branches.","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/3093eb2b83645a083a47ea62769ffd89e31f3664"},{"sha":"4a4f12b2e57e375a318cc2b5089d1c31b986f380","author":{"name":"Commitfest Bot","email":"b9e638e07cc2e2abf56c9c0cad7954f2e3bc1641@cputube.org"},"message":"[CF 23/2151] Allow table AM's to cache stuff in relcache\n\nThis commit was automatically generated by a robot at cfbot.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/23/2151\nPatch(es): https://www.postgresql.org/message-id/dc0a5fe7-9adc-84f7-40e8-a3cde9529a5f@iki.fi\nAuthor(s): Heikki Linnakangas","distinct":true,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/4a4f12b2e57e375a318cc2b5089d1c31b986f380"}]}
{"actor":{"display_login":"postgresql-cfbot"}}