{"push_id":2570208137,"size":4,"distinct_size":1,"ref":"refs/heads/commitfest/18/1618","head":"bc80e96a9b565ab9695d71f6539e427c0fbad0bb","before":"34f6c9b32bad7cfe2bc8539e3c60f1d79175eb25","commits":[{"sha":"7fc7dac1a711d0dbd01d2daf6dc97d27d6c6409c","author":{"name":"Robert Haas","email":"cc4ab156f0be9feefe10b35a552fd319cd7679ae@postgresql.org"},"message":"Pass the correct PlannerInfo to PlanForeignModify/PlanDirectModify.\n\nPreviously, we passed the toplevel PlannerInfo, but we actually want\nto pass the relevant subroot.  One problem with passing the toplevel\nPlannerInfo is that the FDW which wants to push down an UPDATE or\nDELETE against a join won't find the relevant joinrel there.\nAs of commit 1bc0100d270e5bcc980a0629b8726a32a497e788, postgres_fdw\ntries to do exactly this and can be made to fail an assertion as a\nresult.\n\nIt's possible that this should be regarded as a bug fix and\nback-patched to earlier releases, but for lack of a test case that\nfails in earlier releases, no back-patch for now.\n\nEtsuro Fujita, reviewed by Amit Langote.\n\nDiscussion: http://postgr.es/m/5AF43E02.30000@lab.ntt.co.jp","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/7fc7dac1a711d0dbd01d2daf6dc97d27d6c6409c"},{"sha":"a11b3bd37f14386310f25e89529bd3de8cd64383","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Fix misprocessing of equivalence classes involving record_eq().\n\ncanonicalize_ec_expression() is supposed to agree with coerce_type() as to\nwhether a RelabelType should be inserted to make a subexpression be valid\ninput for the operators of a given opclass.  However, it did the wrong\nthing with named-composite-type inputs to record_eq(): it put in a\nRelabelType to RECORDOID, which the parser doesn't.  In some cases this was\nharmless because all code paths involving a particular equivalence class\ndid the same thing, but in other cases this would result in failing to\nrecognize a composite-type expression as being a member of an equivalence\nclass that it actually is a member of.  The most obvious bad effect was to\nfail to recognize that an index on a composite column could provide the\nsort order needed for a mergejoin on that column, as reported by Teodor\nSigaev.  I think there might be other, subtler, cases that result in\nmisoptimization.  It also seems possible that an unwanted RelabelType\nwould sometimes get into an emitted plan --- but because record_eq and\nfriends don't examine the declared type of their input expressions, that\nwould not create any visible problems.\n\nTo fix, just treat RECORDOID as if it were a polymorphic type, which in\nsome sense it is.  We might want to consider formalizing that a bit more\nsomeday, but for the moment this seems to be the only place where an\nIsPolymorphicType() test ought to include RECORDOID as well.\n\nThis has been broken for a long time, so back-patch to all supported\nbranches.\n\nDiscussion: https://postgr.es/m/a6b22369-e3bf-4d49-f59d-0c41d3551e81@sigaev.ru","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/a11b3bd37f14386310f25e89529bd3de8cd64383"},{"sha":"2efc924180f096070d684a712d6c162b6ae0a5e7","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Detoast plpgsql variables if they might live across a transaction boundary.\n\nUp to now, it's been safe for plpgsql to store TOAST pointers in its\nvariables because the ActiveSnapshot for whatever query called the plpgsql\nfunction will surely protect such TOAST values from being vacuumed away,\neven if the owning table rows are committed dead.  With the introduction of\nprocedures, that assumption is no longer good in \"non atomic\" executions\nof plpgsql code.  We adopt the slightly brute-force solution of detoasting\nall TOAST pointers at the time they are stored into variables, if we're in\na non-atomic context, just in case the owning row goes away.\n\nSome care is needed to avoid long-term memory leaks, since plpgsql tends\nto run with CurrentMemoryContext pointing to its call-lifespan context,\nbut we shouldn't assume that no memory is leaked by heap_tuple_fetch_attr.\nIn plpgsql proper, we can do the detoasting work in the \"eval_mcontext\".\n\nMost of the code thrashing here is due to the need to add this capability\nto expandedrecord.c as well as plpgsql proper.  In expandedrecord.c,\nwe can't assume that the caller's context is short-lived, so make use of\nthe short-term sub-context that was already invented for checking domain\nconstraints.  In view of this repurposing, it seems good to rename that\nvariable and associated code from \"domain_check_cxt\" to \"short_term_cxt\".\n\nPeter Eisentraut and Tom Lane\n\nDiscussion: https://postgr.es/m/5AC06865.9050005@anastigmatix.net","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/2efc924180f096070d684a712d6c162b6ae0a5e7"},{"sha":"bc80e96a9b565ab9695d71f6539e427c0fbad0bb","author":{"name":"Commitfest Bot","email":"b9e638e07cc2e2abf56c9c0cad7954f2e3bc1641@cputube.org"},"message":"[CF 18/1618] Exit by default if postmaster dies\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 or the master branch changes.\n\nCommitfest entry: https://commitfest.postgresql.org/18/1618\nPatch(es): https://www.postgresql.org/message-id/CAEepm%3D2xWF53-0FfH%2BuB4ozAuTouxrWTvG%3DuEE_CyhD3OSkPxQ%40mail.gmail.com\nAuthor(s): Thomas Munro","distinct":true,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/bc80e96a9b565ab9695d71f6539e427c0fbad0bb"}]}
{"actor":{"display_login":"postgresql-cfbot"}}