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 1sq9qk-007OMu-7G for pgsql-hackers@arkaria.postgresql.org; Mon, 16 Sep 2024 11:24:59 +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 1sq9qj-00FNQG-9d for pgsql-hackers@arkaria.postgresql.org; Mon, 16 Sep 2024 11:24:57 +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 1sq9qi-00FNQ7-W6 for pgsql-hackers@lists.postgresql.org; Mon, 16 Sep 2024 11:24:56 +0000 Received: from mail-oo1-xc32.google.com ([2607:f8b0:4864:20::c32]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sq9qg-001R61-70 for pgsql-hackers@lists.postgresql.org; Mon, 16 Sep 2024 11:24:55 +0000 Received: by mail-oo1-xc32.google.com with SMTP id 006d021491bc7-5e1b5b617b8so1892175eaf.0 for ; Mon, 16 Sep 2024 04:24:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726485894; x=1727090694; 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=o9j5FDm7Fq794MYRq32LwykRpCfT/WgwqDNl6iPvUec=; b=kzN1hxAxPhjsDHssaxDJcw0ScjQZh2HE4ZJqswQIbOsWjIeB7cKn2nPqUNaXEWy02U 6xpuPIdhkwXDG3FeOpjHezo9DDEbttCzotbdoSkHUJfYY3RmJh/OjLnu04ZTUWZMXx4f LilWkVS+HsLx5ZpF8UwJe8exMw2SWfp8Jr2GnFK8xDosiSX7FUntOt5+tv58TVwm+i/m tuANsf2HGe56jvZ8OuQSzhmK2aEno72mXHQ4Vtd8L4Sz7AegwRcQ4qpYV6VxthLjZXJ0 N9mnm15Jcf/u4seGaA9JWI0t6IUqwQywFfKwwUiois1k8RCi4oUQ9EjZwqUNhNvCyA0i IQUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726485894; x=1727090694; 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=o9j5FDm7Fq794MYRq32LwykRpCfT/WgwqDNl6iPvUec=; b=hcjVzGu/wm5l+rSjHdxrNkOd+OlrQR6/nIHELHp6XiA9Or66rALYsujCOcrj0bc1R5 LT6h+6R/fq4be83coQCHChbcz4ZkNyg5uAlY9p1eDuGgXNX/DBJ6nKTOZAmE6z6ZvBGa kzJTG5+cgqkG45mjx8ZamLQBWnH6pg+qXRtwQiA4WJqIH04WXcLZfz7Gtr6PqcX4L5fx l3s3x3lnkTrUFfdN82CSlLpQGfhV2BN6qgAPceh7dOshPzIW+pwBaz1ABgUfDoVfdtJf pm5FNPGwUny6SiCxKj82Dl3XplMa1GuNPvfTMCRw2KqvxMLZiHljKjk+PxlfME5RKOIU PXfg== X-Forwarded-Encrypted: i=1; AJvYcCVfP3RG8RSfx8t+dC2VkSOsd47cnryR6726K0m6EIUxZC0gXc+DB4h6eQK8zndZu6YJ+Tjw6iDHbdpd/R3O@lists.postgresql.org X-Gm-Message-State: AOJu0YzLGBwg0zxvry4zdZjt5TUvccHkvasPa9YBAOwbgljqdS3tk/o1 u1Zlq7m6HxsuROBnhaRy55qYkUOMduAq2s8h324jvWPvuT47t8ds7CX2IRI1Bf2llvAmCI92KTb graVfsq7hOgAGCndB3oAPcD4CrYc= X-Google-Smtp-Source: AGHT+IHQE+YwDUeut7NCTzXjaosKAjwG0Ed0J9yeLNc+G/qTK16/JrPaUUgySjJ9S/FsWhvwEf2PAWef5+Xe7ucgUF0= X-Received: by 2002:a4a:e544:0:b0:5d5:b51d:e61b with SMTP id 006d021491bc7-5e1e3a798dbmr9545919eaf.0.1726485893674; Mon, 16 Sep 2024 04:24:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Amit Kapila Date: Mon, 16 Sep 2024 16:54:40 +0530 Message-ID: Subject: Re: Introduce XID age and inactive timeout based replication slot invalidation To: Bharath Rupireddy Cc: Peter Smith , Ajin Cherian , Bertrand Drouvot , shveta malik , Masahiko Sawada , 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 Mon, Sep 16, 2024 at 3:31=E2=80=AFPM Bharath Rupireddy wrote: > > Please find the attached v46 patch having changes for the above review > comments and your test review comments and Shveta's review comments. > -ReplicationSlotAcquire(const char *name, bool nowait) +ReplicationSlotAcquire(const char *name, bool nowait, bool error_if_invali= d) { ReplicationSlot *s; int active_pid; @@ -615,6 +620,22 @@ retry: /* We made this slot active, so it's ours now. */ MyReplicationSlot =3D s; + /* + * An error is raised if error_if_invalid is true and the slot has been + * previously invalidated due to inactive timeout. + */ + if (error_if_invalid && + s->data.invalidated =3D=3D RS_INVAL_INACTIVE_TIMEOUT) + { + Assert(s->inactive_since > 0); + ereport(ERROR, + (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE), + errmsg("can no longer get changes from replication slot \"%s\"", + NameStr(s->data.name)), + errdetail("This slot has been invalidated because it was inactive for longer than the amount of time specified by \"%s\".", + "replication_slot_inactive_timeout"))); + } Why raise the ERROR just for timeout invalidation here and why not if the slot is invalidated for other reasons? This raises the question of what happens before this patch if the invalid slot is used from places where we call ReplicationSlotAcquire(). I did a brief code analysis and found that for StartLogicalReplication(), even if the error won't occur in ReplicationSlotAcquire(), it would have been caught in CreateDecodingContext(). I think that is where we should also add this new error. Similarly, pg_logical_slot_get_changes_guts() and other logical replication functions should be calling CreateDecodingContext() which can raise the new ERROR. I am not sure about how the invalid slots are handled during physical replication, please check the behavior of that before this patch. --=20 With Regards, Amit Kapila.