Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rszOw-00B4gT-3F for pgsql-hackers@arkaria.postgresql.org; Sat, 06 Apr 2024 06:19:42 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rszOu-009816-Nz for pgsql-hackers@arkaria.postgresql.org; Sat, 06 Apr 2024 06:19:40 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rszOu-0097yg-EB for pgsql-hackers@lists.postgresql.org; Sat, 06 Apr 2024 06:19:40 +0000 Received: from mail-oa1-x29.google.com ([2001:4860:4864:20::29]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rszOp-000vYZ-15 for pgsql-hackers@postgresql.org; Sat, 06 Apr 2024 06:19:39 +0000 Received: by mail-oa1-x29.google.com with SMTP id 586e51a60fabf-222a9eae9a7so1405019fac.3 for ; Fri, 05 Apr 2024 23:19:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712384373; x=1712989173; darn=postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=cIUicqg2SiOWvXR1IeDJM4Fmn1vgEIEyKpJG5zpy02c=; b=TTa0NwKBInkwdjcpMDc580piq1T3cLnwffr2D3y9MJyyhu5Zw+9xU5BfsAfagVJK0I mlPRncFNFmW7l0dbLCBbkKFn9F259iVVwdbR3rEorwgYrRvlaZiQFjEQZuBtqkSU9sxP 9cEYM9McQWc6EBc9PWzNtx4KNaeOi1VpPHG8tFxuENuHfDic4UEvd7coMajLaPJGQyOU jhTCYIWv9P0rkW2qMe8qzvkbwiBx20ccE9iD2zcM5G5aMnWzswOBTF9Lz+wm+Z7orUq6 EofFUTa59ev7QQ4SB1TrqNZDUt9NSy1B4OsKTu1BQu7J0tDD786X/lY7EHzmf3C8CJQz AhlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712384373; x=1712989173; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=cIUicqg2SiOWvXR1IeDJM4Fmn1vgEIEyKpJG5zpy02c=; b=gJ+vi6hM1Wil+KdTt5vgP6A1qrNd9ZqUhSTnym+ndJkfrmR/YmneUcDPL4tA4b5xyu EQxseSaEcddF53v87tseNKiN97QRi0bg5voJzsLWFPVQyptxrhNktx1zK9JbK9oHZqgB MpdOjhFKChOI8zenr7EbB6AkzP0VXH3C/e+CLSYUKObPyhxRrb4EgG62MSwhsJkIiP4H 7iRct0w+vLgk6dylPak7BkY5ulrxXRPZarnCGzBS065UZP2tlzxcW/VYusBALbCJYRUn LBC/YlG6GxFU95Ola9BfD6fwmdg+KH3UDZYaf+6d0rGBSOwC0ZSLi/cPDj9hNMTBAhqv 95tQ== X-Gm-Message-State: AOJu0YytXzjRtFnNdDPX0o7Kka0Eoe8z6pASUbTbj+SYjNOeGLPbyKzA K0+KTNZG0+pRbU/32Fzx7TnycD+xw7fCoWvea0GhqPEgtCNDtwXK21nfDbRD89AMrf4d1awG6lN RmGwFXngItugexIjVkc76aDhfT1kM85fUkuSvTmm+ X-Google-Smtp-Source: AGHT+IGvLPgxqSIWePgGfej9bjg9X0WNwqgKg2Mb5sqalQZa5wcGcpyN+Y4Uj5BCLGbASwFKxem9WG+eUHEYwx4wf08= X-Received: by 2002:a05:6870:d622:b0:22e:cdf5:40b6 with SMTP id a34-20020a056870d62200b0022ecdf540b6mr3842335oaq.14.1712384373026; Fri, 05 Apr 2024 23:19:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Amit Kapila Date: Sat, 6 Apr 2024 11:49:19 +0530 Message-ID: Subject: Re: promotion related handling in pg_sync_replication_slots() To: shveta malik Cc: pgsql-hackers , Bharath Rupireddy , "Zhijie Hou (Fujitsu)" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Apr 5, 2024 at 10:31=E2=80=AFAM shveta malik wrote: > > Please find v2. Changes are: > 1) Rebased the patch as there was conflict due to recent commit 6f132ed. > 2) Added an Assert in update_synced_slots_inactive_since() to ensure > that the slot does not have active_pid. > 3) Improved commit msg and comments. > Few comments: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. void SyncReplicationSlots(WalReceiverConn *wrconn) { + /* + * Startup process signaled the slot sync to stop, so if meanwhile user + * has invoked slot sync SQL function, simply return. + */ + SpinLockAcquire(&SlotSyncCtx->mutex); + if (SlotSyncCtx->stopSignaled) + { + ereport(LOG, + errmsg("skipping slot synchronization as slot sync shutdown is signaled during promotion")); + + SpinLockRelease(&SlotSyncCtx->mutex); + return; + } + SpinLockRelease(&SlotSyncCtx->mutex); There is a race condition with this code. Say during promotion ShutDownSlotSync() is just before setting this flag and the user has invoked pg_sync_replication_slots() and passed this check but still didn't set the SlotSyncCtx->syncing flag. So, now, the promotion would recognize that there is slot sync going on in parallel, and slot sync wouldn't know that the promotion is in progress. The current coding for slot sync worker ensures there is no such race by checking the stopSignaled and setting the pid together under spinlock. I think we need to move the setting of the syncing flag similarly. Once we do that probably checking SlotSyncCtx->syncing should be sufficient in ShutDownSlotSync(). If we change the location of setting the 'syncing' flag then please ensure its cleanup as we currently do in slotsync_failure_callback(). 2. @@ -1395,6 +1395,7 @@ update_synced_slots_inactive_since(void) if (s->in_use && s->data.synced) { Assert(SlotIsLogical(s)); + Assert(s->active_pid =3D=3D 0); We can add a comment like: "The slot must not be acquired by any process" --=20 With Regards, Amit Kapila.