{"push_id":2026702813,"size":3,"distinct_size":1,"ref":"refs/heads/commitfest/15/1302","head":"a43126ce638fb68188baaeceaf728c0b9516e3fe","before":"72e76488ad8041280f487a93aea8b0063772a6d0","commits":[{"sha":"89e434b59caffeeeb7478653c74ad5d7a50d2e96","author":{"name":"Alvaro Herrera","email":"7cf34a26c111482b1b00703daedc3ff840f1e2cf@alvh.no-ip.org"},"message":"Fix coding rules violations in walreceiver.c\n\n1. Since commit b1a9bad9e744 we had pstrdup() inside a\nspinlock-protected critical section; reported by Andreas Seltenreich.\nTurn those into strlcpy() to stack-allocated variables instead.\nBackpatch to 9.6.\n\n2. Since commit 9ed551e0a4fd we had a pfree() uselessly inside a\nspinlock-protected critical section.  Tom Lane noticed in code review.\nMove down.  Backpatch to 9.6.\n\n3. Since commit 64233902d22b we had GetCurrentTimestamp() (a kernel\ncall) inside a spinlock-protected critical section.  Tom Lane noticed in\ncode review.  Move it up.  Backpatch to 9.2.\n\n4. Since commit 1bb2558046cc we did elog(PANIC) while holding spinlock.\nTom Lane noticed in code review.  Release spinlock before dying.\nBackpatch to 9.2.\n\nDiscussion: https://postgr.es/m/87h8vhtgj2.fsf@ansel.ydns.eu","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/89e434b59caffeeeb7478653c74ad5d7a50d2e96"},{"sha":"45f9d08684d954b0e514b69f270e763d2785dd53","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Fix race condition with unprotected use of a latch pointer variable.\n\nCommit 597a87ccc introduced a latch pointer variable to replace use\nof a long-lived shared latch in the shared WalRcvData structure.\nThis was not well thought out, because there are now hazards of the\npointer variable changing while it's being inspected by another\nprocess.  This could obviously lead to a core dump in code like\n\n\tif (WalRcv->latch)\n\t\tSetLatch(WalRcv->latch);\n\nand there's a more remote risk of a torn read, if we have any\nplatforms where reading/writing a pointer is not atomic.\n\nAn actual problem would occur only if the walreceiver process\nexits (gracefully) while the startup process is trying to\nsignal it, but that seems well within the realm of possibility.\n\nTo fix, treat the pointer variable (not the referenced latch)\nas being protected by the WalRcv->mutex spinlock.  There\nremains a race condition that we could apply SetLatch to a\nprocess latch that no longer belongs to the walreceiver, but\nI believe that's harmless: at worst it'd cause an extra wakeup\nof the next process to use that PGPROC structure.\n\nBack-patch to v10 where the faulty code was added.\n\nDiscussion: https://postgr.es/m/22735.1507048202@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/45f9d08684d954b0e514b69f270e763d2785dd53"},{"sha":"a43126ce638fb68188baaeceaf728c0b9516e3fe","author":{"name":"Commitfest Bot","email":"aab6a594935fe5db0d690bc154b19f642bfbe9d7@cputube.org"},"message":"[CF 15/1302] Make pg_rewind not copy useless WALs\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/15/1302\nPatch(es): https://www.postgresql.org/message-id/7bb9d68d.57.15ece9dfb6f.Coremail.chjischj%40163.com\nAuthor(s): Chen huajun","distinct":true,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/a43126ce638fb68188baaeceaf728c0b9516e3fe"}]}
{"actor":{"display_login":"postgresql-cfbot"}}