{"push_id":2773669354,"size":6,"distinct_size":1,"ref":"refs/heads/commitfest/18/1499","head":"16720810515bf7629c17f2afe1b5c0d36bc78905","before":"054b0385a56ef91ff9efcda537288a0737c1371c","commits":[{"sha":"5a23c74b63ec9f63c648f79b13a900c37332ee55","author":{"name":"Michael Paquier","email":"17b9e1c64588c7fa6419b4d29dc1f4426279ba01@paquier.xyz"},"message":"Reset properly errno before calling write()\n\n6cb3372 enforces errno to ENOSPC when less bytes than what is expected\nhave been written when it is unset, though it forgot to properly reset\nerrno before doing a system call to write(), causing errno to\npotentially come from a previous system call.\n\nReported-by: Tom Lane\nAuthor: Michael Paquier\nReviewed-by: Tom Lane\nDiscussion: https://postgr.es/m/31797.1533326676@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/5a23c74b63ec9f63c648f79b13a900c37332ee55"},{"sha":"b8a1247a34e234be6becf7f70b9f1e8e9369db64","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Fix INSERT ON CONFLICT UPDATE through a view that isn't just SELECT *.\n\nWhen expanding an updatable view that is an INSERT's target, the rewriter\nfailed to rewrite Vars in the ON CONFLICT UPDATE clause.  This accidentally\nworked if the view was just \"SELECT * FROM ...\", as the transformation\nwould be a no-op in that case.  With more complicated view targetlists,\nthis omission would often lead to \"attribute ... has the wrong type\" errors\nor even crashes, as reported by Mario De Frutos Dieguez.\n\nFix by adding code to rewriteTargetView to fix up the data structure\ncorrectly.  The easiest way to update the exclRelTlist list is to rebuild\nit from scratch looking at the new target relation, so factor the code\nfor that out of transformOnConflictClause to make it sharable.\n\nIn passing, avoid duplicate permissions checks against the EXCLUDED\npseudo-relation, and prevent useless view expansion of that relation's\ndummy RTE.  The latter is only known to happen (after this patch) in cases\nwhere the query would fail later due to not having any INSTEAD OF triggers\nfor the view.  But by exactly that token, it would create an unintended\nand very poorly tested state of the query data structure, so it seems like\na good idea to prevent it from happening at all.\n\nThis has been broken since ON CONFLICT was introduced, so back-patch\nto 9.5.\n\nDean Rasheed, based on an earlier patch by Amit Langote;\ncomment-kibitzing and back-patching by me\n\nDiscussion: https://postgr.es/m/CAFYwGJ0xfzy8jaK80hVN2eUWr6huce0RU8AgU04MGD00igqkTg@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/b8a1247a34e234be6becf7f70b9f1e8e9369db64"},{"sha":"7a46068f47a2e407d80d9d552727dc102188bec2","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Update version 11 release notes.\n\nRemove description of commit 1944cdc98, which has now been back-patched\nso it's not relevant to v11 any longer.  Add descriptions of other\nrecent commits that seemed worth mentioning.\n\nI marked the update as stopping at 2018-07-30, because it's unclear\nwhether d06eebce5 will be allowed to stay in v11, and I didn't feel like\nputting effort into writing a description of it yet.  If it does stay,\nI think it will deserve mention in the Source Code section.","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/7a46068f47a2e407d80d9d552727dc102188bec2"},{"sha":"77291139c7c1dffac61e8db88cef98933677db18","author":{"name":"Heikki Linnakangas","email":"ac1e0af1ee8efe15f889b38482e897ff7d0f0432@iki.fi"},"message":"Remove support for tls-unique channel binding.\n\nThere are some problems with the tls-unique channel binding type. It's not\nsupported by all SSL libraries, and strictly speaking it's not defined for\nTLS 1.3 at all, even though at least in OpenSSL, the functions used for it\nstill seem to work with TLS 1.3 connections. And since we had no\nmechanism to negotiate what channel binding type to use, there would be\nawkward interoperability issues if a server only supported some channel\nbinding types. tls-server-end-point seems feasible to support with any SSL\nlibrary, so let's just stick to that.\n\nThis removes the scram_channel_binding libpq option altogether, since there\nis now only one supported channel binding type.\n\nThis also removes all the channel binding tests from the SSL test suite.\nThey were really just testing the scram_channel_binding option, which\nis now gone. Channel binding is used if both client and server support it,\nso it is used in the existing tests. It would be good to have some tests\nspecifically for channel binding, to make sure it really is used, and the\ndifferent combinations of a client and a server that support or doesn't\nsupport it. The current set of settings we have make it hard to write such\ntests, but I did test those things manually, by disabling\nHAVE_BE_TLS_GET_CERTIFICATE_HASH and/or\nHAVE_PGTLS_GET_PEER_CERTIFICATE_HASH.\n\nI also removed the SCRAM_CHANNEL_BINDING_TLS_END_POINT constant. This is a\nmatter of taste, but IMO it's more readable to just use the\n\"tls-server-end-point\" string.\n\nRefactor the checks on whether the SSL library supports the functions\nneeded for tls-server-end-point channel binding. Now the server won't\nadvertise, and the client won't choose, the SCRAM-SHA-256-PLUS variant, if\ncompiled with an OpenSSL version too old to support it.\n\nIn the passing, add some sanity checks to check that the chosen SASL\nmechanism, SCRAM-SHA-256 or SCRAM-SHA-256-PLUS, matches whether the SCRAM\nexchange used channel binding or not. For example, if the client selects\nthe non-channel-binding variant SCRAM-SHA-256, but in the SCRAM message\nuses channel binding anyway. It's harmless from a security point of view,\nI believe, and I'm not sure if there are some other conditions that would\ncause the connection to fail, but it seems better to be strict about these\nthings and check explicitly.\n\nDiscussion: https://www.postgresql.org/message-id/ec787074-2305-c6f4-86aa-6902f98485a4%40iki.fi","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/77291139c7c1dffac61e8db88cef98933677db18"},{"sha":"6b9eb503d28b1e6d94961d2aee833c931a887ee6","author":{"name":"Heikki Linnakangas","email":"ac1e0af1ee8efe15f889b38482e897ff7d0f0432@iki.fi"},"message":"Remove now unused check for HAVE_X509_GET_SIGNATURE_NID in test.\n\nI removed the code that used this in the previous commit.\n\nSpotted by Michael Paquier.","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/6b9eb503d28b1e6d94961d2aee833c931a887ee6"},{"sha":"16720810515bf7629c17f2afe1b5c0d36bc78905","author":{"name":"Commitfest Bot","email":"b9e638e07cc2e2abf56c9c0cad7954f2e3bc1641@cputube.org"},"message":"[CF 18/1499] Add missing type conversion functions for PL/Python\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/1499\nPatch(es): https://www.postgresql.org/message-id/7d8ee2bc-7c9b-48d1-f8f0-1cd2cd439165@postgrespro.ru\nAuthor(s): Haozhou Wang","distinct":true,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/16720810515bf7629c17f2afe1b5c0d36bc78905"}]}
{"actor":{"display_login":"postgresql-cfbot"}}