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 1rsEnw-005iYj-7M for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Apr 2024 04:34:24 +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 1rsEnv-00EVrs-9N for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Apr 2024 04:34:23 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rsEnu-00EVrj-Us for pgsql-hackers@lists.postgresql.org; Thu, 04 Apr 2024 04:34:22 +0000 Received: from mail-lj1-x230.google.com ([2a00:1450:4864:20::230]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rsEnq-000TIv-Fd for pgsql-hackers@lists.postgresql.org; Thu, 04 Apr 2024 04:34:21 +0000 Received: by mail-lj1-x230.google.com with SMTP id 38308e7fff4ca-2d82713f473so8949901fa.3 for ; Wed, 03 Apr 2024 21:34:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712205256; x=1712810056; darn=lists.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=TIxb7NKS/jw9kI1Epetw+lb4iwbLTCIDNJQAkbduiIE=; b=dkK/xvjqcsFl3+FDOsGTmcVKS7sZqp9bIIkAEO51q8qrW2bNEuEpK7YpF2254T3WKc AJZJvb+1K5QVtR3myacK8SJUN5uLzwUz1JPjVh9Ly1slOyz8P3IRThNYtrnQtO++GENW TDuWNUNQXsINBdyLs0Rvn9hxGWs644PWWlgL7mwWoTj3TWiStbgRhR5WcD9bt09/rKcY PKCCdneVfCSNh4q9e35uIVHIylkyrR4U8mY4plOMKwiUAbbPGUC6B8mqOhjTG+ifEfJW jgWrlzTPzq16RHC2uleiDRz+8A9R7aRsu31lAhj6kYSd8NzLLu+KxMBcTHP9i6lgM5ld cXsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712205256; x=1712810056; 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=TIxb7NKS/jw9kI1Epetw+lb4iwbLTCIDNJQAkbduiIE=; b=TBP0XuGjn9WXx+DGoD6cNaRJkThMPntXQf7jRX+lg/mAv548F4UqOABEwnpebWBXpP f+wk8mU6fPejTlt8PlORAJzx9J01VisrYolYnQ8/MHJIqzfvhvK2sdTaWzNKW3IGuh21 /eKioKhMX0S0gMNbM51BunAY54JhNqp0DIq1GLNrPscDZSf1tXHDnQL0S9DqrRm8GiT7 NO0nHUh7AGZ3bnoWnVAfXgxukJ0I0odpU/Xq+h4PnWtu4nLLYjQdzaEA1dwk/wkOPqOt 9+heqX8iwG7ZtK5wbiqld+ABRGp/0EnIigZOdRCTGocpMkyCR7q3MGb4s42siBXIzSc4 gohQ== X-Forwarded-Encrypted: i=1; AJvYcCVL2tWMR7ippN8Z5lsfD1juaY2+vlZJHko+o54A5BifN4+F8RKB998I1daxIvnwdMAhUPxNRDfG3jb6rG06TcWoJB3t+7H/s+VVR661LdyfAD8Z X-Gm-Message-State: AOJu0Yxc8AQI6i6P/rHFqQbUkAosCTvqc735eQ4ekzoxH49YgdetZRR7 +R5MbG2/0Gpn3pcVYixJrCDrYVkKHpGXvmbG2yzaf9nMTSvFOy7uAnRvuTao90YM7tZ22OY60jF tpzD/hmdgsOEhdRfWq4ZtGaWks+s= X-Google-Smtp-Source: AGHT+IFfRs6hOhDumgT/PR0Xt0d4OtBpEiU8a3nC5qxNhurVSm/iIQWTXYo+lefPFwo40mwvy7AUh8Eb0a18K1C3Xqs= X-Received: by 2002:a2e:3c10:0:b0:2d8:5779:470e with SMTP id j16-20020a2e3c10000000b002d85779470emr457222lja.17.1712205255539; Wed, 03 Apr 2024 21:34:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Bharath Rupireddy Date: Thu, 4 Apr 2024 10:04:02 +0530 Message-ID: Subject: Re: Introduce XID age and inactive timeout based replication slot invalidation To: Masahiko Sawada Cc: Bertrand Drouvot , shveta malik , Amit Kapila , Nathan Bossart , PostgreSQL Hackers 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 Thu, Apr 4, 2024 at 9:42=E2=80=AFAM Masahiko Sawada wrote: > > @@ -1368,6 +1416,7 @@ ShutDownSlotSync(void) > if (SlotSyncCtx->pid =3D=3D InvalidPid) > { > SpinLockRelease(&SlotSyncCtx->mutex); > + update_synced_slots_inactive_since(); > return; > } > SpinLockRelease(&SlotSyncCtx->mutex); > @@ -1400,6 +1449,8 @@ ShutDownSlotSync(void) > } > > SpinLockRelease(&SlotSyncCtx->mutex); > + > + update_synced_slots_inactive_since(); > } > > Why do we want to update all synced slots' inactive_since values at > shutdown in spite of updating the value every time when releasing the > slot? It seems to contradict the fact that inactive_since is updated > when releasing or restoring the slot. It is to get the inactive_since right for the cases where the standby is promoted without a restart similar to when a standby is promoted with restart in which case the inactive_since is set to current time in RestoreSlotFromDisk. Imagine the slot is synced last time at time t1 and then a few hours passed, the standby is promoted without a restart. If we don't set inactive_since to current time in this case in ShutDownSlotSync, the inactive timeout invalidation mechanism can kick in immediately. --=20 Bharath Rupireddy PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com