{"push_id":3062113672,"size":9,"distinct_size":1,"ref":"refs/heads/commitfest/21/1878","head":"a2fcf3d17d5313269f3f8efe6ffff2af68857c04","before":"aab6f51a8aeaa1986d7e6e5055dc57873b246524","commits":[{"sha":"d5d7f7f3b78e00009ee87ad01d1fb87b28968f65","author":{"name":"Andrew Dunstan","email":"02e0a999c50b1f88df7a8f5a04e1b76b35ea6a88@dunslane.net"},"message":"Silence MSVC warnings about redefinition of isnan\n\nSome versions of perl.h define isnan when the compiler is MSVC. To avoid\nwarnings about this, undefine the symbol before including perl.h and\nre-add the definition afterwards if it wasn't recreated.\n\nDiscussion: https://postgr.es/m/caf0568e-3c1f-07fd-6914-d903f22560f2@2ndQuadrant.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/d5d7f7f3b78e00009ee87ad01d1fb87b28968f65"},{"sha":"79376e07128fbf3c92f4e1fb457be435afa2e6a6","author":{"name":"Andrew Dunstan","email":"02e0a999c50b1f88df7a8f5a04e1b76b35ea6a88@dunslane.net"},"message":"fix typo","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/79376e07128fbf3c92f4e1fb457be435afa2e6a6"},{"sha":"285bd0ac4a7c0538d544c40aa725682e11cb71a9","author":{"name":"Michael Paquier","email":"17b9e1c64588c7fa6419b4d29dc1f4426279ba01@paquier.xyz"},"message":"Remove unnecessary memcpy when reading WAL record fitting on page\n\nWhen reading a WAL record, its contents are copied into an intermediate\nbuffer.  However, doing so is not necessary if the record fits fully\ninto the current page, saving one memcpy for each such record.  The\nallocation handling of the intermediate buffer is also now done only\nwhen a record crosses a page boundary, shaving some extra cycles when\nreading a WAL record.\n\nAuthor: Andrey Lepikhov\nReviewed-by: Kyotaro Horiguchi, Heikki Linnakangas\nDiscussion: https://postgr.es/m/c2ea54dd-a1d3-80eb-ddbf-7e6f258e615e@postgrespro.ru","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/285bd0ac4a7c0538d544c40aa725682e11cb71a9"},{"sha":"74171f8c12e68408f1fa895fdee36fdc8b0a9f79","author":{"name":"Michael Paquier","email":"17b9e1c64588c7fa6419b4d29dc1f4426279ba01@paquier.xyz"},"message":"Rework documentation of pg_promote\n\nThis clarifies the behavior of how the \"wait\" flag works, which is\nsomething that the previous version of the documentation failed to do.\n\nAuthor: Ian Barwick\nDiscussion: https://postgr.es/m/cbd38450-2295-10a1-1f73-591a692ae0b0@2ndquadrant.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/74171f8c12e68408f1fa895fdee36fdc8b0a9f79"},{"sha":"1556cb2fc5c774c3f7390dd6fb19190ee0c73f8b","author":{"name":"Thomas Munro","email":"1ff054ef0838bf068a4b7c40eef026e560a37025@postgresql.org"},"message":"Don't forget about failed fsync() requests.\n\nIf fsync() fails, md.c must keep the request in its bitmap, so that\nfuture attempts will try again.\n\nBack-patch to all supported releases.\n\nAuthor: Thomas Munro\nReviewed-by: Amit Kapila\nReported-by: Andrew Gierth\nDiscussion: https://postgr.es/m/87y3i1ia4w.fsf%40news-spur.riddles.org.uk","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/1556cb2fc5c774c3f7390dd6fb19190ee0c73f8b"},{"sha":"9ccdd7f66e3324d2b6d3dec282cfa9ff084083f1","author":{"name":"Thomas Munro","email":"1ff054ef0838bf068a4b7c40eef026e560a37025@postgresql.org"},"message":"PANIC on fsync() failure.\n\nOn some operating systems, it doesn't make sense to retry fsync(),\nbecause dirty data cached by the kernel may have been dropped on\nwrite-back failure.  In that case the only remaining copy of the\ndata is in the WAL.  A subsequent fsync() could appear to succeed,\nbut not have flushed the data.  That means that a future checkpoint\ncould apparently complete successfully but have lost data.\n\nTherefore, violently prevent any future checkpoint attempts by\npanicking on the first fsync() failure.  Note that we already\ndid the same for WAL data; this change extends that behavior to\nnon-temporary data files.\n\nProvide a GUC data_sync_retry to control this new behavior, for\nusers of operating systems that don't eject dirty data, and possibly\nforensic/testing uses.  If it is set to on and the write-back error\nwas transient, a later checkpoint might genuinely succeed (on a\nsystem that does not throw away buffers on failure); if the error is\npermanent, later checkpoints will continue to fail.  The GUC defaults\nto off, meaning that we panic.\n\nBack-patch to all supported releases.\n\nThere is still a narrow window for error-loss on some operating\nsystems: if the file is closed and later reopened and a write-back\nerror occurs in the intervening time, but the inode has the bad\nluck to be evicted due to memory pressure before we reopen, we could\nmiss the error.  A later patch will address that with a scheme\nfor keeping files with dirty data open at all times, but we judge\nthat to be too complicated to back-patch.\n\nAuthor: Craig Ringer, with some adjustments by Thomas Munro\nReported-by: Craig Ringer\nReviewed-by: Robert Haas, Thomas Munro, Andres Freund\nDiscussion: https://postgr.es/m/20180427222842.in2e4mibx45zdth5%40alap3.anarazel.de","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/9ccdd7f66e3324d2b6d3dec282cfa9ff084083f1"},{"sha":"fc47e99a157a56a92dea679a74d546e28b253bb7","author":{"name":"Peter Eisentraut","email":"c50e6bf7013fce877ffb25104d778a36de31e297@gmx.net"},"message":"pg_archivecleanup: Update file header comment a bit","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/fc47e99a157a56a92dea679a74d546e28b253bb7"},{"sha":"5c9a5513a3967367e5fcc9237bc4146f4b24b408","author":{"name":"Alvaro Herrera","email":"3c84f0de6f8a0f296d36cdd9f57fa166641c96b1@alvh.no-ip.org"},"message":"Disallow COPY FREEZE on partitioned tables\n\nThis didn't actually work: COPY would fail to flush the right files, and\ninstead would try to flush a non-existing file, causing the whole\ntransaction to fail.\n\nCope by raising an error as soon as the command is sent instead, to\navoid a nasty later surprise.  Of course, it would be much better to\nmake it work, but we don't have a patch for that yet, and we don't know\nif we'll want to backpatch one when we do.\n\nReported-by: Tomas Vondra\nAuthor: David Rowley\nReviewed-by: Amit Langote, Steve Singer, Tomas Vondra","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/5c9a5513a3967367e5fcc9237bc4146f4b24b408"},{"sha":"a2fcf3d17d5313269f3f8efe6ffff2af68857c04","author":{"name":"Commitfest Bot","email":"b9e638e07cc2e2abf56c9c0cad7954f2e3bc1641@cputube.org"},"message":"[CF 21/1878] More issues with pg_verify_checksums and checksum verification in base backups\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/1878\nPatch(es): https://www.postgresql.org/message-id/20181025.175742.27133880.horiguchi.kyotaro@lab.ntt.co.jp\nAuthor(s): Michael Paquier","distinct":true,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/a2fcf3d17d5313269f3f8efe6ffff2af68857c04"}]}
{"actor":{"display_login":"postgresql-cfbot"}}