{"push_id":3171613590,"size":6,"distinct_size":1,"ref":"refs/heads/commitfest/21/1951","head":"c66fddb5dd103df6a4fc718eaa510bbecb4ae777","before":"09c7861a91726ad716a642442e021120badcab1d","commits":[{"sha":"e3299d36a938c7af386b240f318c7b9e55bdc92d","author":{"name":"Peter Eisentraut","email":"4b8373d016f277527198385ba72fda0feb5da015@eisentraut.org"},"message":"Remove redundant translation markers\n\npsql_error() already handles that itself.","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/e3299d36a938c7af386b240f318c7b9e55bdc92d"},{"sha":"1a4eba4e246480466c04feb81f76866e7dcb2827","author":{"name":"Peter Eisentraut","email":"4b8373d016f277527198385ba72fda0feb5da015@eisentraut.org"},"message":"pg_rewind: Add missing newline to error message","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/1a4eba4e246480466c04feb81f76866e7dcb2827"},{"sha":"6645ad6bdd81e7d5a764e0d94ef52fae053a9e13","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Use a separate random seed for SQL random()/setseed() functions.\n\nPreviously, the SQL random() function depended on libc's random(3),\nand setseed() invoked srandom(3).  This results in interference between\nthese functions and backend-internal uses of random(3).  We'd never paid\ntoo much mind to that, but in the wake of commit 88bdbd3f7 which added\nlog_statement_sample_rate, the interference arguably has a security\nconsequence: if log_statement_sample_rate is active then an unprivileged\nuser could probably control which if any of his SQL commands get logged,\nby issuing setseed() at the right times.  That seems bad.\n\nTo fix this reliably, we need random() and setseed() to use their own\nprivate random state variable.  Standard random(3) isn't amenable to such\nusage, so let's switch to pg_erand48().  It's hard to say whether that's\nmore or less \"random\" than any particular platform's version of random(3),\nbut it does have a wider seed value and a longer period than are required\nby POSIX, so we can hope that this isn't a big downgrade.  Also, we should\nnow have uniform behavior of random() across platforms, which is worth\nsomething.\n\nWhile at it, upgrade the per-process seed initialization method to use\npg_strong_random() if available, greatly reducing the predictability\nof the initial seed value.  (I'll separately do something similar for\nthe internal uses of random().)\n\nIn addition to forestalling the possible security problem, this has a\nbenefit in the other direction, which is that we can now document\nsetseed() as guaranteeing a reproducible sequence of random() values.\nPreviously, because of the possibility of internal calls of random(3),\nwe could not promise any such thing.\n\nDiscussion: https://postgr.es/m/3859.1545849900@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/6645ad6bdd81e7d5a764e0d94ef52fae053a9e13"},{"sha":"4203842a1cd06a7c30fd3eaae1c111928909e539","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Use pg_strong_random() to select each server process's random seed.\n\nPreviously we just set the seed based on process ID and start timestamp.\nBoth those values are directly available within the session, and can\nbe found out or guessed by other users too, making the session's series\nof random(3) values fairly predictable.  Up to now, our backend-internal\nuses of random(3) haven't seemed security-critical, but commit 88bdbd3f7\nadded one that potentially is: when using log_statement_sample_rate, a\nuser might be able to predict which of his SQL statements will get logged.\n\nTo improve this situation, upgrade the per-process seed initialization\nmethod to use pg_strong_random() if available, greatly reducing the\npredictability of the initial seed value.  This adds a few tens of\nmicroseconds to process start time, but since backend startup time is\nat least a couple of milliseconds, that seems an acceptable price.\n\nThis means that pg_strong_random() needs to be able to run without\nreliance on any backend infrastructure, since it will be invoked\nbefore any of that is up.  It was safe for that already, but adjust\ncomments and #include commands to make it clearer.\n\nDiscussion: https://postgr.es/m/3859.1545849900@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/4203842a1cd06a7c30fd3eaae1c111928909e539"},{"sha":"e0ef136d5235f39f5652c209c08a5d4322560e9c","author":{"name":"Michael Paquier","email":"17b9e1c64588c7fa6419b4d29dc1f4426279ba01@paquier.xyz"},"message":"Trigger stmt_beg and stmt_end for top-level statement blocks of PL/pgSQL\n\nPL/pgSQL provides a set of callbacks which can be used for extra\ninstrumentation of functions written in this language called at function\nsetup, begin and end, as well as statement begin and end.  When calling\na routine, a trigger, or an event trigger, statement callbacks are not\ngetting called for the top-level statement block leading to an\ninconsistent handling compared to the other statements.  This\ninconsistency can potentially complicate extensions doing\ninstrumentation work on top of PL/pgSQL, so this commit makes sure that\nall statement blocks, including the top-level one, go through the\ncorrect corresponding callbacks.\n\nAuthor: Pavel Stehule\nReviewed-by: Michael Paquier\nDiscussion: https://postgr.es/m/CAFj8pRArEANsaUjo5in9_iQt0vKf9ecwDAmsdN_EBwL13ps12A@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/e0ef136d5235f39f5652c209c08a5d4322560e9c"},{"sha":"c66fddb5dd103df6a4fc718eaa510bbecb4ae777","author":{"name":"Commitfest Bot","email":"b9e638e07cc2e2abf56c9c0cad7954f2e3bc1641@cputube.org"},"message":"[CF 21/1951] Temporary materialized views\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/21/1951\nPatch(es): https://www.postgresql.org/message-id/CAKLmikPwgRmfCLnmyzx2Tcb=19=C=d3+n18VxfeCCKutTjqDQA@mail.gmail.com\nAuthor(s): Mi Tar","distinct":true,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/c66fddb5dd103df6a4fc718eaa510bbecb4ae777"}]}
{"actor":{"display_login":"postgresql-cfbot"}}