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 1rsI37-00664u-IB for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Apr 2024 08:02:18 +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 1rsI36-00Habj-Jx for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Apr 2024 08:02:16 +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 1rsI36-00Habb-A1 for pgsql-hackers@lists.postgresql.org; Thu, 04 Apr 2024 08:02:16 +0000 Received: from mail-lj1-x232.google.com ([2a00:1450:4864:20::232]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rsI2z-000Utq-99 for pgsql-hackers@lists.postgresql.org; Thu, 04 Apr 2024 08:02:14 +0000 Received: by mail-lj1-x232.google.com with SMTP id 38308e7fff4ca-2d71f9e07a9so1481811fa.1 for ; Thu, 04 Apr 2024 01:02:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712217728; x=1712822528; 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=frLwVMDaMGoDMbcn0MNNRUQF9Jz1eJS85B9PZ9GNVsM=; b=DQUly26epuvPXmTBRwnXkGlxe0LJW/4nrw1wD2Asyz50f4TQ1OeDQ4k3nfG7klj/Sc S/V2+KFHtxnzSIT9bw13gd27YUW9ILgZ+fXFm340Dq5bEvYtnz9+AfC8ROZ5DYiYMC7l PrabXda1FymLDMB/RmhXF7ySIkRK/pxxzQDZqFNBAYuAZSlADILL+4wctvJVv82WQ+WA 0MhIong3oWMn6YWqSrZgrT6HDKPMmq7Ar8iemBP2R1wJkMFDs0BgByTBN6t0tCCibebj 9HsV68tvIlMq6SWTUyatKgnG7tnO/KfKPJaFJdhgu1Aiq/ttN1lAT32BmwoY89Rx2CX5 Z9gQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712217728; x=1712822528; 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=frLwVMDaMGoDMbcn0MNNRUQF9Jz1eJS85B9PZ9GNVsM=; b=DZOJmCig/2YAirjfYx4qMo5pEHVYV0cIpsXnMAdkBgvuCY/RSYm0gj6xj3+wKpkAxM gBzmBjWpFO53vJw6bYWNrflC5kMuxdo9yO21/tOh1sG9AkapJBpZM9p3RKjNbEbSe4e/ sQlbRi0McvtGysisW7SeJ4n7fSIB/tbaMWs0R9wQo4O+SSA8Fc7lgHDJat6e2J5faAQc aosvJlxou+ZhUqGIL5SvemfhWQ7zeWf72wCv3veUMp0m4nP08x8mFEBEEk35H/0IWSXd 0E744id73Tsn6L8T9aAiOw+KAHE2PrtN2B8XetMvwVLzOxDTYIbQLqF/6KfipLsxxGYb qItA== X-Forwarded-Encrypted: i=1; AJvYcCUIkscpTtGSp7ZhRo3LJrT0o3D5Lwi+qkc7nyHyPh4hRNaM4HkyPbAmM8NGWp/VwZOxKAz0xUIs2wSLF+isSnon6ELoHrKYazVBzQ825nW6Y72d X-Gm-Message-State: AOJu0YyqrUslQ24xUXfYnWE3TGw5tAmLlTXU9JTMTW+MoQlK55pELs7l +Foz4TYe2Kjg/dcEUk37wRt8KJZ+GVwIMKIyC1UD+1nqAPyQVatH9FvIvMeubBg1Z4TY0xbOiaJ c2i9XHh0s6uuJdcAMRlhmRSO/U44= X-Google-Smtp-Source: AGHT+IEs4VO5Zcp1REiWhsdeXPwIr33kqE/4eRVuHvFtqrsgzudHJ6D052B2aAleZ/VCDpr/wlBu5ZCPzXv9Cw48GrI= X-Received: by 2002:a2e:804f:0:b0:2d6:b698:968 with SMTP id p15-20020a2e804f000000b002d6b6980968mr1003292ljg.1.1712217727460; Thu, 04 Apr 2024 01:02:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Masahiko Sawada Date: Thu, 4 Apr 2024 17:01:30 +0900 Message-ID: Subject: Re: Introduce XID age and inactive timeout based replication slot invalidation To: Bharath Rupireddy 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 1:34=E2=80=AFPM Bharath Rupireddy wrote: > > 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. > Thank you for the explanation! I understood the needs. Regards, --=20 Masahiko Sawada Amazon Web Services: https://aws.amazon.com