{"push_id":2027099318,"size":3,"distinct_size":1,"ref":"refs/heads/commitfest/15/1155","head":"82337c997b19ba8b7ac6ffe5a276c13e4350d48a","before":"9206d51853c0bdc6917eddbacecfb5268ca00d42","commits":[{"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":"11d8d72c27a64ea4e30adce11cf6c4f3dd3e60db","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Allow multiple tables to be specified in one VACUUM or ANALYZE command.\n\nNot much to say about this; does what it says on the tin.\n\nHowever, formerly, if there was a column list then the ANALYZE action was\nimplied; now it must be specified, or you get an error.  This is because\nit would otherwise be a bit unclear what the user meant if some tables\nhave column lists and some don't.\n\nNathan Bossart, reviewed by Michael Paquier and Masahiko Sawada, with some\neditorialization by me\n\nDiscussion: https://postgr.es/m/E061A8E3-5E3D-494D-94F0-E8A9B312BBFC@amazon.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/11d8d72c27a64ea4e30adce11cf6c4f3dd3e60db"},{"sha":"82337c997b19ba8b7ac6ffe5a276c13e4350d48a","author":{"name":"Commitfest Bot","email":"aab6a594935fe5db0d690bc154b19f642bfbe9d7@cputube.org"},"message":"[CF 15/1155] Add --no-comments to skip COMMENTs with pg_dump\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/1155\nPatch(es): https://www.postgresql.org/message-id/CAEP4nAy%2B0MBJmOUA0ScyETPDo0VrBNoEb67m_%2BVBByi7Ajs03Q%40mail.gmail.com\nAuthor(s): Robins Tharakan","distinct":true,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/82337c997b19ba8b7ac6ffe5a276c13e4350d48a"}]}
{"actor":{"display_login":"postgresql-cfbot"}}