{"push_id":2713201931,"size":11,"distinct_size":1,"ref":"refs/heads/commitfest/18/1460","head":"6edbcc9d2b4d3cf80fc43a9a09646980ad06ab2a","before":"c47dbfdc523437e3fa7034d8e8dbfde022dda19e","commits":[{"sha":"56a714721343e6f52c0b1b911c0f160592348e84","author":{"name":"Michael Paquier","email":"17b9e1c64588c7fa6419b4d29dc1f4426279ba01@paquier.xyz"},"message":"Block replication slot advance for these not yet reserving WAL\n\nSuch replication slots are physical slots freshly created without WAL\nbeing reserved, which is the default behavior, which have not been used\nyet as WAL consumption resources to retain WAL.  This prevents advancing\na slot to a position older than any WAL available, which could falsify\ncalculations for WAL segment recycling.\n\nThis also cleans up a bit the code, as ReplicationSlotRelease() would be\ncalled on ERROR, and improves error messages.\n\nReported-by: Kyotaro Horiguchi\nAuthor: Michael Paquier\nReviewed-by: Andres Freund, Álvaro Herrera, Kyotaro Horiguchi\nDiscussion: https://postgr.es/m/20180626071305.GH31353@paquier.xyz","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/56a714721343e6f52c0b1b911c0f160592348e84"},{"sha":"9f09529952ac41a10e5874cba745c1c24e67ac79","author":{"name":"Thomas Munro","email":"1ff054ef0838bf068a4b7c40eef026e560a37025@postgresql.org"},"message":"Use signals for postmaster death on Linux.\n\nLinux provides a way to ask for a signal when your parent process dies.\nUse that to make PostmasterIsAlive() very cheap.\n\nBased on a suggestion from Andres Freund.\n\nAuthor: Thomas Munro, Heikki Linnakangas\nReviewed-By: Michael Paquier\nDiscussion: https://postgr.es/m/7261eb39-0369-f2f4-1bb5-62f3b6083b5e%40iki.fi\nDiscussion: https://postgr.es/m/20180411002643.6buofht4ranhei7k%40alap3.anarazel.de","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/9f09529952ac41a10e5874cba745c1c24e67ac79"},{"sha":"f98b8476cd4a19dfc602ab95642ce08e53877d65","author":{"name":"Thomas Munro","email":"1ff054ef0838bf068a4b7c40eef026e560a37025@postgresql.org"},"message":"Use signals for postmaster death on FreeBSD.\n\nUse FreeBSD 11.2's new support for detecting parent process death to\nmake PostmasterIsAlive() very cheap, as was done for Linux in an\nearlier commit.\n\nAuthor: Thomas Munro\nDiscussion: https://postgr.es/m/7261eb39-0369-f2f4-1bb5-62f3b6083b5e@iki.fi","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/f98b8476cd4a19dfc602ab95642ce08e53877d65"},{"sha":"a01d0fa1d889cc2003e1941e8b98707c4d701ba9","author":{"name":"Alexander Korotkov","email":"1c137998207470ad0f56303c4fc305487ec0232f@postgresql.org"},"message":"Fix wrong file path in header comment\n\nHeader comment of shm_mq.c was mistakenly specifying path to shm_mq.h.\nIt was introduced in ec9037df.  So, theoretically it could be\nbackpatched to 9.4, but it doesn't seem to worth it.","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/a01d0fa1d889cc2003e1941e8b98707c4d701ba9"},{"sha":"f2c587067a8eb9cf1c8f009262381a6576ba3dd0","author":{"name":"Alvaro Herrera","email":"3c84f0de6f8a0f296d36cdd9f57fa166641c96b1@alvh.no-ip.org"},"message":"Rethink how to get float.h in old Windows API for isnan/isinf\n\nWe include <float.h> in every place that needs isnan(), because MSVC\nused to require it.  However, since MSVC 2013 that's no longer necessary\n(cf. commit cec8394b5ccd), so we can retire the inclusion to a\nversion-specific stanza in win32_port.h, where it doesn't need to\npollute random .c files.  The header is of course still needed in a few\nplaces for other reasons.\n\nI (Álvaro) removed float.h from a few more files than in Emre's original\npatch.  This doesn't break the build in my system, but we'll see what\nthe buildfarm has to say about it all.\n\nAuthor: Emre Hasegeli\nDiscussion: https://postgr.es/m/CAE2gYzyc0+5uG+Cd9-BSL7NKC8LSHLNg1Aq2=8ubjnUwut4_iw@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/f2c587067a8eb9cf1c8f009262381a6576ba3dd0"},{"sha":"edf59c40dd6f477ca867c8958d9665ab1bff0265","author":{"name":"Alexander Korotkov","email":"1c137998207470ad0f56303c4fc305487ec0232f@postgresql.org"},"message":"Fix more wrong paths in header comments\n\nIt appears that there are more files, whose header comment paths are\nwrong.  So, fix those paths.  No backpatching per proposal of Tom Lane.\n\nDiscussion: https://postgr.es/m/CAPpHfdsJyYbOj59MOQL%2B4XxdcomLSLfLqBtAvwR%2BpsCqj3ELdQ%40mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/edf59c40dd6f477ca867c8958d9665ab1bff0265"},{"sha":"ff4f8891648c804c7c126fdf438257b1e9dc7ca4","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Fix bugs with degenerate window ORDER BY clauses in GROUPS/RANGE mode.\n\nnodeWindowAgg.c failed to cope with the possibility that no ordering\ncolumns are defined in the window frame for GROUPS mode or RANGE OFFSET\nmode, leading to assertion failures or odd errors, as reported by Masahiko\nSawada and Lukas Eder.  In RANGE OFFSET mode, an ordering column is really\nrequired, so add an Assert about that.  In GROUPS mode, the code would\nwork, except that the node initialization code wasn't in sync with the\nexecution code about when to set up tuplestore read pointers and spare\nslots.  Fix the latter for consistency's sake (even though I think the\nchanges described below make the out-of-sync cases unreachable for now).\n\nPer SQL spec, a single ordering column is required for RANGE OFFSET mode,\nand at least one ordering column is required for GROUPS mode.  The parser\nenforced the former but not the latter; add a check for that.\n\nWe were able to reach the no-ordering-column cases even with fully spec\ncompliant queries, though, because the planner would drop partitioning\nand ordering columns from the generated plan if they were redundant with\nearlier columns according to the redundant-pathkey logic, for instance\n\"PARTITION BY x ORDER BY y\" in the presence of a \"WHERE x=y\" qual.\nWhile in principle that's an optimization that could save some pointless\ncomparisons at runtime, it seems unlikely to be meaningful in the real\nworld.  I think this behavior was not so much an intentional optimization\nas a side-effect of an ancient decision to construct the plan node's\nordering-column info by reverse-engineering the PathKeys of the input\npath.  If we give up redundant-column removal then it takes very little\ncode to generate the plan node info directly from the WindowClause,\nensuring that we have the expected number of ordering columns in all\ncases.  (If anyone does complain about this, the planner could perhaps\nbe taught to remove redundant columns only when it's safe to do so,\nie *not* in RANGE OFFSET mode.  But I doubt anyone ever will.)\n\nWith these changes, the WindowAggPath.winpathkeys field is not used for\nanything anymore, so remove it.\n\nThe test cases added here are not actually very interesting given the\nremoval of the redundant-column-removal logic, but they would represent\nimportant corner cases if anyone ever tries to put that back.\n\nTom Lane and Masahiko Sawada.  Back-patch to v11 where RANGE OFFSET\nand GROUPS modes were added.\n\nDiscussion: https://postgr.es/m/CAD21AoDrWqycq-w_+Bx1cjc+YUhZ11XTj9rfxNiNDojjBx8Fjw@mail.gmail.com\nDiscussion: https://postgr.es/m/153086788677.17476.8002640580496698831@wrigleys.postgresql.org","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/ff4f8891648c804c7c126fdf438257b1e9dc7ca4"},{"sha":"57cd2b6e6dc571cf65983d2aa86065d6d006f152","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Fix create_scan_plan's handling of sortgrouprefs for physical tlists.\n\nWe should only run apply_pathtarget_labeling_to_tlist if CP_LABEL_TLIST\nwas specified, because only in that case has use_physical_tlist checked\nthat the labeling will succeed; otherwise we may get an \"ORDER/GROUP BY\nexpression not found in targetlist\" error.  (This subsumes the previous\ntest about gating_clauses, because we reset \"flags\" to zero earlier\nif there are gating clauses to apply.)\n\nThe only known case in which a failure can occur is with a ProjectSet\npath directly atop a table scan path, although it seems likely that there\nare other cases or will be such in future.  This means that the failure\nis currently only visible in the v10 branch: 9.6 didn't have ProjectSet,\nwhile in v11 and HEAD, apply_scanjoin_target_to_paths for some weird\nreason is using create_projection_path not apply_projection_to_path,\nmasking the problem because there's a ProjectionPath in between.\n\nNonetheless this code is clearly wrong on its own terms, so back-patch\nto 9.6 where this logic was introduced.\n\nPer report from Regina Obe.\n\nDiscussion: https://postgr.es/m/001501d40f88$75186950$5f493bf0$@pcorp.us","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/57cd2b6e6dc571cf65983d2aa86065d6d006f152"},{"sha":"39a96512b3ed72de7b24b2667d9575d7e9fcb326","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Mark built-in btree comparison functions as leakproof where it's safe.\n\nGenerally, if the comparison operators for a datatype or pair of datatypes\nare leakproof, the corresponding btree comparison support function can be\nconsidered so as well.  But we had not originally worried about marking\nsupport functions as leakproof, reasoning that they'd not likely be used in\nqueries so the marking wouldn't matter.  It turns out there's at least one\nplace where it does matter: calc_arraycontsel() finds the target datatype's\ndefault btree comparison function and tries to use that to estimate\nselectivity, but it will be blocked in some cases if the function isn't\nleakproof.  This leads to unnecessarily poor selectivity estimates and bad\nplans, as seen in bug #15251.\n\nHence, run around and apply proleakproof markings where the corresponding\nbtree comparison operators are leakproof.  (I did eyeball each function\nto verify that it wasn't doing anything surprising, too.)\n\nThis isn't a full solution to bug #15251, and it's not back-patchable\nbecause of the need for a catversion bump.  A more useful response probably\nis to consider whether we can check permissions on the parent table instead\nof the child.  However, this change will help in some cases where that\nwon't, and it's easy enough to do in HEAD, so let's do so.\n\nDiscussion: https://postgr.es/m/3876.1531261875@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/39a96512b3ed72de7b24b2667d9575d7e9fcb326"},{"sha":"9a7b7adc130a197e5c993a99e6aaa981f9341a35","author":{"name":"Michael Paquier","email":"17b9e1c64588c7fa6419b4d29dc1f4426279ba01@paquier.xyz"},"message":"Make logical WAL sender report streaming state appropriately\n\nWAL senders sending logically-decoded data fail to properly report in\n\"streaming\" state when starting up, hence as long as one extra record is\nnot replayed, such WAL senders would remain in a \"catchup\" state, which\nis inconsistent with the physical cousin.\n\nThis can be easily reproduced by for example using pg_recvlogical and\nrestarting the upstream server.  The TAP tests have been slightly\nmodified to detect the failure and strengthened so as future tests also\nmake sure that a node is in streaming state when waiting for its\ncatchup.\n\nBackpatch down to 9.4 where this code has been introduced.\n\nReported-by: Sawada Masahiko\nAuthor: Simon Riggs, Sawada Masahiko\nReviewed-by: Petr Jelinek, Michael Paquier, Vaishnavi Prabakaran\nDiscussion: https://postgr.es/m/CAD21AoB2ZbCCqOx=bgKMcLrAvs1V0ZMqzs7wBTuDySezTGtMZA@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/9a7b7adc130a197e5c993a99e6aaa981f9341a35"},{"sha":"6edbcc9d2b4d3cf80fc43a9a09646980ad06ab2a","author":{"name":"Commitfest Bot","email":"b9e638e07cc2e2abf56c9c0cad7954f2e3bc1641@cputube.org"},"message":"[CF 18/1460] Sample values for pg_stat_statements\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/18/1460\nPatch(es): https://www.postgresql.org/message-id/d2aa6acb-537a-b4be-c27b-993df61918c1@2ndquadrant.com\nAuthor(s): Vik Fearing","distinct":true,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/6edbcc9d2b4d3cf80fc43a9a09646980ad06ab2a"}]}
{"actor":{"display_login":"postgresql-cfbot"}}