Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jP8oP-0000ol-El for pgsql-hackers@arkaria.postgresql.org; Thu, 16 Apr 2020 18:00:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jP8oO-0006aT-BO for pgsql-hackers@arkaria.postgresql.org; Thu, 16 Apr 2020 18:00:28 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jP8oO-0006aK-4z for pgsql-hackers@lists.postgresql.org; Thu, 16 Apr 2020 18:00:28 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jP8oM-0008Oa-2T for pgsql-hackers@lists.postgresql.org; Thu, 16 Apr 2020 18:00:27 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id 03GI0NsI030111; Thu, 16 Apr 2020 14:00:23 -0400 From: Tom Lane To: Fujii Masao cc: Kyotaro Horiguchi , masahiko.sawada@2ndquadrant.com, pgsql-hackers@lists.postgresql.org Subject: Re: Race condition in SyncRepGetSyncStandbysPriority In-reply-to: <43ecec68-abff-6cdb-8412-204451d650ac@oss.nttdata.com> References: <20200413.153101.688623432137444694.horikyota.ntt@gmail.com> <8325.1586828060@sss.pgh.pa.us> <20200414.183538.344904915964423903.horikyota.ntt@gmail.com> <15616.1586872362@sss.pgh.pa.us> <43ecec68-abff-6cdb-8412-204451d650ac@oss.nttdata.com> Comments: In-reply-to Fujii Masao message dated "Fri, 17 Apr 2020 02:20:04 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <30109.1587060023.1@sss.pgh.pa.us> Date: Thu, 16 Apr 2020 14:00:23 -0400 Message-ID: <30110.1587060023@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Fujii Masao writes: > On 2020/04/14 22:52, Tom Lane wrote: >> *Yes it does*. The existing code can deliver entirely broken results >> if some walsender exits between where we examine the priorities and >> where we fetch the WAL pointers. > IMO that the broken results can be delivered when walsender marked > as sync exits *and* new walsender comes at that moment. If this new > walsender uses the WalSnd slot that the exited walsender used, > SyncRepGetOldestSyncRecPtr() wronly calculates the oldest lsn based > on this new walsender (i.e., different walsender from one marked as sync). Right, exactly, sorry that I was not more specific. > BTW, since the patch changes the API of SyncRepGetSyncStandbys(), > it should not be back-patched to avoid ABI break. Right? Anything that is using that is just as broken as the core code is, for the same reasons, so I don't have a problem with changing its API. Maybe we should rename it while we're at it, just to make it clear that we are breaking any external callers. (If there are any, which seems somewhat unlikely.) The only concession to ABI that I had in mind was to not re-order the fields of WalSnd in the back branches. regards, tom lane