{"push_id":2889062859,"size":6,"distinct_size":1,"ref":"refs/heads/commitfest/19/1530","head":"61b4cc1d862ff8fa8478bc936ff76c345850e942","before":"d1c12de739ccd5bdb12a05a351ce81d73404da4a","commits":[{"sha":"422952ee78220c49812b7697c7855c6230840e35","author":{"name":"Thomas Munro","email":"1ff054ef0838bf068a4b7c40eef026e560a37025@postgresql.org"},"message":"Allow DSM allocation to be interrupted.\n\nChris Travers reported that the startup process can repeatedly try to\ncancel a backend that is in a posix_fallocate()/EINTR loop and cause it\nto loop forever.  Teach the retry loop to give up if an interrupt is\npending.  Don't actually check for interrupts in that loop though,\nbecause a non-local exit would skip some clean-up code in the caller.\n\nBack-patch to 9.4 where DSM was added (and posix_fallocate() was later\nback-patched).\n\nAuthor: Chris Travers\nReviewed-by: Ildar Musin, Murat Kabilov, Oleksii Kliukin\nTested-by: Oleksii Kliukin\nDiscussion: https://postgr.es/m/CAN-RpxB-oeZve_J3SM_6%3DHXPmvEG%3DHX%2B9V9pi8g2YR7YW0rBBg%40mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/422952ee78220c49812b7697c7855c6230840e35"},{"sha":"09991e5a475bc7ed17168cbc8dd5673de4366463","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Fix some probably-minor oversights in readfuncs.c.\n\nThe system expects TABLEFUNC RTEs to have coltypes, coltypmods, and\ncolcollations lists, but outfuncs doesn't dump them and readfuncs doesn't\nrestore them.  This doesn't cause obvious failures, because the only things\nthat look at those fields are expandRTE() and get_rte_attribute_type(),\nwhich are mostly used during parse analysis, before anything would've\npassed the parsetree through outfuncs/readfuncs.  But expandRTE() is used\nin build_physical_tlist(), which means that that function will return a\nwrong answer for a TABLEFUNC RTE that came from a view.  Very accidentally,\nthis doesn't cause serious problems, because what it will return is NIL\nwhich callers will interpret as \"couldn't build a physical tlist because\nof dropped columns\".  So you still get a plan that works, though it's\nmarginally less efficient than it could be.  There are also some other\nexpandRTE() calls associated with transformation of whole-row Vars in\nthe planner.  I have been unable to exhibit misbehavior from that, and\nit may be unreachable in any case that anyone would care about ... but\nI'm not entirely convinced, so this seems like something we should back-\npatch a fix for.  Fortunately, we can fix it without forcing a change\nof stored rules and a catversion bump, because we can just copy these\nlists from the subsidiary TableFunc object.\n\nreadfuncs.c was also missing support for NamedTuplestoreScan plan nodes.\nThis accidentally fails to break parallel query because a query using\na named tuplestore would never be considered parallel-safe anyway.\nHowever, project policy since parallel query came in is that all plan\nnode types should have outfuncs/readfuncs support, so this is clearly\nan oversight that should be repaired.\n\nNoted while fooling around with a patch to test outfuncs/readfuncs more\nthoroughly.  That exposed some other issues too, but these are the only\nones that seem worth back-patching.\n\nBack-patch to v10 where both of these features came in.\n\nDiscussion: https://postgr.es/m/17114.1537138992@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/09991e5a475bc7ed17168cbc8dd5673de4366463"},{"sha":"db1071d4ee9f0e348ab646e7c13184d480d40516","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Fix some minor issues exposed by outfuncs/readfuncs testing.\n\nA test patch to pass parse and plan trees through outfuncs + readfuncs\nexposed several issues that need to be fixed to get clean matches:\n\nQuery.withCheckOptions failed to get copied; it's intentionally ignored\nby outfuncs/readfuncs on the grounds that it'd always be NIL anyway in\nstored rules.  This seems less than future-proof, and it's not even\nsaving very much, so just undo the decision and treat the field like\nall others.\n\nSeveral places that convert a view RTE into a subquery RTE, or similar\nmanipulations, failed to clear out fields that were specific to the\noriginal RTE type and should be zero in a subquery RTE.  Since readfuncs.c\nwill leave such fields as zero, equalfuncs.c thinks the nodes are different\nleading to a reported mismatch.  It seems like a good idea to clear out the\nno-longer-needed fields, even though in principle nothing should look at\nthem; the node ought to be indistinguishable from how it would look if\nwe'd built a new node instead of scribbling on the old one.\n\nBuildOnConflictExcludedTargetlist randomly set the resname of some\nTargetEntries to \"\" not NULL.  outfuncs/readfuncs don't distinguish those\ncases, and so the string will read back in as NULL ... but equalfuncs.c\ndoes distinguish.  Perhaps we ought to try to make things more consistent\nin this area --- but it's just useless extra code space for\nBuildOnConflictExcludedTargetlist to not use NULL here, so I fixed it for\nnow by making it do that.\n\ncatversion bumped because the change in handling of Query.withCheckOptions\naffects stored rules.\n\nDiscussion: https://postgr.es/m/17114.1537138992@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/db1071d4ee9f0e348ab646e7c13184d480d40516"},{"sha":"d0cfc3d6a44af1756ca5be8cb2414da7b8bf20d5","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Add a debugging option to stress-test outfuncs.c and readfuncs.c.\n\nIn the normal course of operation, query trees will be serialized only if\nthey are stored as views or rules; and plan trees will be serialized only\nif they get passed to parallel-query workers.  This leaves an awful lot of\nopportunity for bugs/oversights to not get detected, as indeed we've just\nbeen reminded of the hard way.\n\nTo improve matters, this patch adds a new compile option\nWRITE_READ_PARSE_PLAN_TREES, which is modeled on the longstanding option\nCOPY_PARSE_PLAN_TREES; but instead of passing all parse and plan trees\nthrough copyObject, it passes them through nodeToString + stringToNode.\nEnabling this option in a buildfarm animal or two will catch problems\nat least for cases that are exercised by the regression tests.\n\nA small problem with this idea is that readfuncs.c historically has\ndiscarded location fields, on the reasonable grounds that parse\nlocations in a retrieved view are not relevant to the current query.\nBut doing that in WRITE_READ_PARSE_PLAN_TREES breaks pg_stat_statements,\nand it could cause problems for future improvements that might try to\nreport error locations at runtime.  To fix that, provide a variant\nbehavior in readfuncs.c that makes it restore location fields when\ntold to.\n\nIn passing, const-ify the string arguments of stringToNode and its\nsubsidiary functions, just because it annoyed me that they weren't\nconst already.\n\nDiscussion: https://postgr.es/m/17114.1537138992@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/d0cfc3d6a44af1756ca5be8cb2414da7b8bf20d5"},{"sha":"2a6368343ff43743ddd90d0f4c2d0ac03e18aa85","author":{"name":"Alexander Korotkov","email":"1c137998207470ad0f56303c4fc305487ec0232f@postgresql.org"},"message":"Add support for nearest-neighbor (KNN) searches to SP-GiST\n\nCurrently, KNN searches were supported only by GiST.  SP-GiST also capable to\nsupport them.  This commit implements that support.  SP-GiST scan stack is\nreplaced with queue, which serves as stack if no ordering is specified.  KNN\nsupport is provided for three SP-GIST opclasses: quad_point_ops, kd_point_ops\nand poly_ops (catversion is bumped).  Some common parts between GiST and SP-GiST\nKNNs are extracted into separate functions.\n\nDiscussion: https://postgr.es/m/570825e8-47d0-4732-2bf6-88d67d2d51c8%40postgrespro.ru\nAuthor: Nikita Glukhov, Alexander Korotkov based on GSoC work by Vlad Sterzhanov\nReview: Andrey Borodin, Alexander Korotkov","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/2a6368343ff43743ddd90d0f4c2d0ac03e18aa85"},{"sha":"61b4cc1d862ff8fa8478bc936ff76c345850e942","author":{"name":"Commitfest Bot","email":"b9e638e07cc2e2abf56c9c0cad7954f2e3bc1641@cputube.org"},"message":"[CF 19/1530] Speed up WAL file removal during recovery\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/19/1530\nPatch(es): https://www.postgresql.org/message-id/0A3221C70F24FB45833433255569204D1F81B0C8@G01JPEXMBYT05\nAuthor(s): Takayuki Tsunakawa","distinct":true,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/61b4cc1d862ff8fa8478bc936ff76c345850e942"}]}
{"actor":{"display_login":"postgresql-cfbot"}}