{"push_id":3078204392,"size":3,"distinct_size":1,"ref":"refs/heads/commitfest/20/1802","head":"a86f5317c438d5244995a89c8a5de658adbea7e4","before":"034d415b4480759e337290335d040f90617990b7","commits":[{"sha":"d5890f49da6a77b1325a3f5822c6b092a2cd41ae","author":{"name":"Andrew Gierth","email":"f5e6496b0ff21826a604b558aceee3773835e92d@postgresql.org"},"message":"Fix hstore hash function for empty hstores upgraded from 8.4.\n\nHstore data generated on pg 8.4 and pg_upgraded to current versions\nremains in its original on-disk format unless modified. The same goes\nfor values generated by the addon hstore-new module on pre-9.0\nversions. (The hstoreUpgrade function converts old values on the fly\nwhen read in, but the on-disk value is not modified by this.)\n\nSince old-format empty hstores (and hstore-new hstores) have\nrepresentations compatible with the new format, hstoreUpgrade thought\nit could get away without modifying such values; but this breaks\nhstore_hash (and the new hstore_hash_extended) which assumes\nbit-perfect matching between semantically identical hstore values.\nOnly one bit actually differs (the \"new version\" flag in the count\nfield) but that of course is enough to break the hash.\n\nFix by making hstoreUpgrade unconditionally convert all old values to\nnew format.\n\nBackpatch all the way, even though this changes a hash value in some\ncases, because in those cases the hash value is already failing - for\nexample, a hash join between old- and new-format empty hstores will be\nfailing to match, or a hash index on an hstore column containing an\nold-format empty value will be failing to find the value since it will\nbe searching for a hash derived from a new-format datum. (There are no\nknown field reports of this happening, probably because hashing of\nhstores has only been useful in limited circumstances and there\nprobably isn't much upgraded data being used this way.)\n\nPer concerns arising from discussion of commit eb6f29141be. Original\nbug is my fault.\n\nDiscussion: https://postgr.es/m/60b1fd3b-7332-40f0-7e7f-f2f04f777747%402ndquadrant.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/d5890f49da6a77b1325a3f5822c6b092a2cd41ae"},{"sha":"ab69ea9feeb9a02c6299b5c1b786005552343f22","author":{"name":"Thomas Munro","email":"1ff054ef0838bf068a4b7c40eef026e560a37025@postgresql.org"},"message":"Fix assertion failure for SSL connections.\n\nCommit cfdf4dc4 added an assertion that every WaitLatch() or similar\nhandles postmaster death.  One place did not, but was missed in\nreview and testing due to the need for an SSL connection.  Fix, by\nasking for WL_EXIT_ON_PM_DEATH.\n\nReported-by: Christoph Berg\nDiscussion: https://postgr.es/m/20181124143845.GA15039%40msg.df7cb.de","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/ab69ea9feeb9a02c6299b5c1b786005552343f22"},{"sha":"a86f5317c438d5244995a89c8a5de658adbea7e4","author":{"name":"Commitfest Bot","email":"b9e638e07cc2e2abf56c9c0cad7954f2e3bc1641@cputube.org"},"message":"[CF 20/1802] Retail IndexTuple Deletion\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/20/1802\nPatch(es): https://www.postgresql.org/message-id/c5a8f52b-6b61-e6f6-aa22-0f4bd0909b63@postgrespro.ru\nAuthor(s): Andrey Lepikhov","distinct":true,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/a86f5317c438d5244995a89c8a5de658adbea7e4"}]}
{"actor":{"display_login":"postgresql-cfbot"}}