{"push_id":3883163474,"size":11,"distinct_size":1,"ref":"refs/heads/commitfest/24/2222","head":"af7ad225cdbe30d076bad304839720635cb264a8","before":"718e47e89c07fe4a7e136d7230aeb08390ed92f1","commits":[{"sha":"b2a3d706b8d76b9d65e953942fc1ccafe892f692","author":{"name":"Michael Paquier","email":"17b9e1c64588c7fa6419b4d29dc1f4426279ba01@paquier.xyz"},"message":"Fix handling of previous password hooks in passwordcheck\n\nWhen piling up loading of modules using check_password_hook_type,\nloading passwordcheck would remove any trace of a previously-loaded\nhook.  Unloading the module would also cause previous hooks to be\nentirely gone.\n\nReported-by: Rafael Castro\nAuthor: Michael Paquier\nReviewed-by: Daniel Gustafsson\nDiscussion: https://postgr.es/m/15932-78f48f9ef166778c@postgresql.org\nBackpatch-through: 9.4","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/b2a3d706b8d76b9d65e953942fc1ccafe892f692"},{"sha":"fd6ec93bf890314ac694dc8a7f3c45702ecc1bbd","author":{"name":"Peter Eisentraut","email":"4b8373d016f277527198385ba72fda0feb5da015@eisentraut.org"},"message":"Add error codes to some corruption log messages\n\nIn some cases we have elog(ERROR) while corruption is certain and we\ncan give a clear error code ERRCODE_DATA_CORRUPTED or\nERRCODE_INDEX_CORRUPTED.\n\nAuthor: Andrey Borodin <x4mmm@yandex-team.ru>\nDiscussion: https://www.postgresql.org/message-id/flat/25F6C686-6442-4A6B-BAF8-A6F7B84B16DE@yandex-team.ru","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/fd6ec93bf890314ac694dc8a7f3c45702ecc1bbd"},{"sha":"4886da8327507dddd830786b0c7aaa9cfc480b4b","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Mark advisory-lock functions as parallel restricted, not parallel unsafe.\n\nThere seems no good reason not to allow a parallel leader to execute\nthese functions.  (The workers still can't, though.  Although the code\nwould work, any such lock would go away at worker exit, which is not\nthe documented behavior of advisory locks.)\n\nDiscussion: https://postgr.es/m/11847.1564496844@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/4886da8327507dddd830786b0c7aaa9cfc480b4b"},{"sha":"da9456d22a7697ef2c5ba9dd1402d948b2ec7f09","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Add an isolation test to exercise parallel-worker deadlock resolution.\n\nCommit a1c1af2a1 added logic in the deadlock checker to handle lock\ngrouping, but it was very poorly tested, as evidenced by the bug\nfixed in 3420851a2.  Add a test case that exercises that a bit better\n(and catches the bug --- if you revert 3420851a2, this will hang).\n\nSince it's pretty hard to get parallel workers to take exclusive\nregular locks that their parents don't already have, this test operates\nby creating a deadlock among advisory locks taken in parallel workers.\nTo make that happen, we must override the parallel-safety labeling of\nthe advisory-lock functions, which we do by putting them in mislabeled,\nnon-inlinable wrapper functions.\n\nWe also have to remove the redundant PreventAdvisoryLocksInParallelMode\nchecks in lockfuncs.c.  That seems fine though; if some user accidentally\ndoes what this test is intentionally doing, not much harm will ensue.\n(If there are any remaining bugs that are reachable that way, they're\nprobably reachable in other ways too.)\n\nDiscussion: https://postgr.es/m/3243.1564437314@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/da9456d22a7697ef2c5ba9dd1402d948b2ec7f09"},{"sha":"71dcd7438664d81235c72337cbbbfa780f7a0630","author":{"name":"Peter Geoghegan","email":"96dd8d96902e9c5af3b96b1eaa9c80cbc615d290@bowt.ie"},"message":"Add sort support routine for the inet data type.\n\nAdd sort support for inet, including support for abbreviated keys.\nTesting has shown that this reduces the time taken to sort medium to\nlarge inet/cidr inputs by ~50-60% in realistic cases.\n\nAuthor: Brandur Leach\nReviewed-By: Peter Geoghegan, Edmund Horner\nDiscussion: https://postgr.es/m/CABR_9B-PQ8o2MZNJ88wo6r-NxW2EFG70M96Wmcgf99G6HUQ3sw@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/71dcd7438664d81235c72337cbbbfa780f7a0630"},{"sha":"a8d6a95eb992e942838e41029537564d81c4a50e","author":{"name":"Peter Geoghegan","email":"96dd8d96902e9c5af3b96b1eaa9c80cbc615d290@bowt.ie"},"message":"Bump catversion.\n\nOversight in commit 71dcd743.","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/a8d6a95eb992e942838e41029537564d81c4a50e"},{"sha":"7266d0997dd2a0632da38a594c78e25ff21df67e","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Allow functions-in-FROM to be pulled up if they reduce to constants.\n\nThis allows simplification of the plan tree in some common usage\npatterns: we can get rid of a join to the function RTE.\n\nIn principle we could pull up any immutable expression, but restricting\nit to Consts avoids the risk that multiple evaluations of the expression\nmight cost more than we can save.  (Possibly this could be improved in\nfuture --- but we've more or less promised people that putting a function\nin FROM guarantees single evaluation, so we'd have to tread carefully.)\n\nTo do this, we need to rearrange when eval_const_expressions()\nhappens for expressions in function RTEs.  I moved it to\ninline_set_returning_functions(), which already has to iterate over\nevery function RTE, and in consequence renamed that function to\npreprocess_function_rtes().  A useful consequence is that\ninline_set_returning_function() no longer has to do this for itself,\nsimplifying that code.\n\nIn passing, break out pull_up_simple_subquery's code that knows where\neverything that needs pullup_replace_vars() processing is, so that\nthe new pull_up_constant_function() routine can share it.  We'd\ngotten away with one-and-a-half copies of that code so far, since\npull_up_simple_values() could assume that a lot of cases didn't apply\nto it --- but I don't think pull_up_constant_function() can make any\nsimplifying assumptions.  Might as well make pull_up_simple_values()\nuse it too.\n\n(Possibly this refactoring should go further: maybe we could share\nsome of the code to fill in the pullup_replace_vars_context struct?\nFor now, I left it that the callers fill that completely.)\n\nNote: the one existing test case that this patch changes has to be\nchanged because inlining its function RTEs would destroy the point\nof the test, namely to check join order.\n\nAlexander Kuzmenkov and Aleksandr Parfenov, reviewed by\nAntonin Houska and Anastasia Lubennikova, and whacked around\nsome more by me\n\nDiscussion: https://postgr.es/m/402356c32eeb93d4fed01f66d6c7fe2d@postgrespro.ru","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/7266d0997dd2a0632da38a594c78e25ff21df67e"},{"sha":"6ae4e8eae78e0781633f7b40a1b5cc189bc40923","author":{"name":"Jeff Davis","email":"a6043a059331789899fcd6238d9fdd7ab2ab417a@postgresql.org"},"message":"Allow simplehash to use already-calculated hash values.\n\nAdd _lookup_hash and _insert_hash functions for callers that have\nalready calculated the hash value of the key.\n\nThe immediate use case is for hash algorithms that write to disk in\npartitions. The hash value can be calculated once, used to perform a\nlookup, used to select the partition, then written to the partition\nalong with the tuple. When the tuple is read back, the hash value does\nnot need to be recalculated.\n\nAuthor: Jeff Davis\nReviewed-by: Andres Freund\nDiscussion: https://postgr.es/m/48abe675e1330f0c264ab2fe0d4ff23eb244f9ef.camel%40j-davis.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/6ae4e8eae78e0781633f7b40a1b5cc189bc40923"},{"sha":"a9f301df0e76c38d4544477c1b3e5e29d57904e6","author":{"name":"Michael Paquier","email":"17b9e1c64588c7fa6419b4d29dc1f4426279ba01@paquier.xyz"},"message":"Fix format truncation issue from ECPG test\n\nThis fixes one warning generated by GCC and present in the test case\narray part of ECPG.  This likely got missed in past fixes like 3a4b891\nbecause the compilation of those tests is not done by default.\n\nReported-by: Sergei Kornilov\nDiscussion: https://postgr.es/m/14951331562847675@sas2-a1efad875d04.qloud-c.yandex.net","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/a9f301df0e76c38d4544477c1b3e5e29d57904e6"},{"sha":"2abd7ae9b20bcd810d4f19d28aefb97048813825","author":{"name":"Andres Freund","email":"883768b6dd2c42aea0031b24be8a2da40fef4b64@anarazel.de"},"message":"Fix representation of hash keys in Hash/HashJoin nodes.\n\nIn 5f32b29c1819 I changed the creation of HashState.hashkeys to\nactually use HashState as the parent (instead of HashJoinState, which\nwas incorrect, as they were executed below HashState), to fix the\nproblem of hashkeys expressions otherwise relying on slot types\nappropriate for HashJoinState, rather than HashState as would be\ncorrect. That reliance was only introduced in 12, which is why it\npreviously worked to use HashJoinState as the parent (although I'd be\nunsurprised if there were problematic cases).\n\nUnfortunately that's not a sufficient solution, because before this\ncommit, the to-be-hashed expressions referenced inner/outer as\nappropriate for the HashJoin, not Hash. That didn't have obvious bad\nconsequences, because the slots containing the tuples were put into\necxt_innertuple when hashing a tuple for HashState (even though Hash\ndoesn't have an inner plan).\n\nThere are less common cases where this can cause visible problems\nhowever (rather than just confusion when inspecting such executor\ntrees). E.g. \"ERROR: bogus varno: 65000\", when explaining queries\ncontaining a HashJoin where the subsidiary Hash node's hash keys\nreference a subplan. While normally hashkeys aren't displayed by\nEXPLAIN, if one of those expressions references a subplan, that\nsubplan may be printed as part of the Hash node - which then failed\nbecause an inner plan was referenced, and Hash doesn't have that.\n\nIt seems quite possible that there's other broken cases, too.\n\nFix the problem by properly splitting the expression for the HashJoin\nand Hash nodes at plan time, and have them reference the proper\nsubsidiary node. While other workarounds are possible, fixing this\ncorrectly seems easy enough. It was a pretty ugly hack to have\nExecInitHashJoin put the expression into the already initialized\nHashState, in the first place.\n\nI decided to not just split inner/outer hashkeys inside\nmake_hashjoin(), but also to separate out hashoperators and\nhashcollations at plan time. Otherwise we would have ended up having\ntwo very similar loops, one at plan time and the other during executor\nstartup. The work seems to more appropriately belong to plan time,\nanyway.\n\nReported-By: Nikita Glukhov, Alexander Korotkov\nAuthor: Andres Freund\nReviewed-By: Tom Lane, in an earlier version\nDiscussion: https://postgr.es/m/CAPpHfdvGVegF_TKKRiBrSmatJL2dR9uwFCuR+teQ_8tEXU8mxg@mail.gmail.com\nBackpatch: 12-","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/2abd7ae9b20bcd810d4f19d28aefb97048813825"},{"sha":"af7ad225cdbe30d076bad304839720635cb264a8","author":{"name":"Commitfest Bot","email":"b9e638e07cc2e2abf56c9c0cad7954f2e3bc1641@cputube.org"},"message":"[CF 24/2222] Redacting information from logs\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/24/2222\nPatch(es): https://www.postgresql.org/message-id/f859d7d263c263d12b638c67ede65d937640740f.camel@j-davis.com\nAuthor(s): Jeff Davis","distinct":true,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/af7ad225cdbe30d076bad304839720635cb264a8"}]}
{"actor":{"display_login":"postgresql-cfbot"}}