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 1slgzp-000cdy-70 for pgsql-hackers@arkaria.postgresql.org; Wed, 04 Sep 2024 03:47:53 +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 1slgzn-003QKi-Kk for pgsql-hackers@arkaria.postgresql.org; Wed, 04 Sep 2024 03:47:52 +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 1slgzn-003QKa-A1 for pgsql-hackers@lists.postgresql.org; Wed, 04 Sep 2024 03:47:51 +0000 Received: from mail-wr1-x42d.google.com ([2a00:1450:4864:20::42d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1slgzl-000387-7L for pgsql-hackers@lists.postgresql.org; Wed, 04 Sep 2024 03:47:50 +0000 Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-374c8cef906so2016572f8f.2 for ; Tue, 03 Sep 2024 20:47:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725421666; x=1726026466; 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=xi7cjKL+5peb9DwYAX4JibgDXu3/taXj5p8ZR2p9ZVs=; b=Z+PpbovZStABmXh5p7P2dT2W0LlIdU6Dy/e0K1Xnd8Vldpl6U4RVQFs3pwGsS/s/lf TllogOdir20pEXsgyc1mObSC+RRuNiziwCt+BkuTroyLowlM5ZVGaB0EIvKLXlTcuOHB Z+QcRRaQx+yZMTcU8B8NrnTPerM0WVBpa/8KSL085mifVPJi8+wduR3D+zf26q/CY+7A eJhjlMEj9BYsr6e7j9bnxPVITlj9LqOFYxXSY/wekRdyiqtGE6/jbKfeC2KI2HX0FzpI C+n+0EF4Kf5n06S+Erg/G46Hki8Vuc8S5pUesxBhQMppjZoqjVQb7VZijJd7lgX3Kp1+ 2d5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725421666; x=1726026466; 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=xi7cjKL+5peb9DwYAX4JibgDXu3/taXj5p8ZR2p9ZVs=; b=uq/ySCjP1yd92aLsTSS2wM4OCU0TCZ2QWZ4zYzonmapM9xJX6PxymhKb11/i3Q45rV KGas5o/i6lbDV17hSNYV9lqa2scDYJ8ClHw7aZ0qsCdHucMGdmzzsIZlkVolpp4m48DE pczhA5TFcsJ6G6NPlNjA7s9uyhDd0hRpdyXP/3/B4cH5xR1w8T+lyfH/zDAL8f0nkRah PK/3jBU474Z13h97d6iKlFTy7OSaKb/axAoQcUNC3/XCmKoBfKv9yxho9AVO0RA4M5eK YOV/FW/1DFXucIO3w/u/4G78WYpxSEAlizRgqUT3d/OpoIJVvSf2+K+zV6rKTORrRnGm UKDQ== X-Forwarded-Encrypted: i=1; AJvYcCUyA9qyR4SfvFlMPhmY13sDYbxzlL2KCffpz0nkrJx4mjpU5TH+1Qo+OUb10xAZl4O/+cwAe+QhhZmAyhpN@lists.postgresql.org X-Gm-Message-State: AOJu0YyowL3WPFqKoo/KI8+aveYLlwe/fiy5JC6uu9tm4hmmlRKd5p6c lkSi9mzMD2NF8VVqKKHIB2sVL3MsHVOpmtEOa5MbOpLEJn/SeFCO0xnHo+eblR348Mo1aBfExES QIlfBlQL9/4oHAS8LGwXNhqvnntM= X-Google-Smtp-Source: AGHT+IHh3a1QEIWu5e7+HxpiUO/kXxIDvpx0Gx1vuqK1XT7gCZ3I75CJ/znA0ncB7zFi+FXiVN0vx5Ak8d+FSRuw73A= X-Received: by 2002:adf:cd0a:0:b0:374:ba7b:42af with SMTP id ffacd0b85a97d-376dd15b687mr1905312f8f.26.1725421665498; Tue, 03 Sep 2024 20:47:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Wed, 4 Sep 2024 09:17:33 +0530 Message-ID: Subject: Re: Introduce XID age and inactive timeout based replication slot invalidation To: Bharath Rupireddy Cc: Peter Smith , Amit Kapila , Ajin Cherian , Bertrand Drouvot , Masahiko Sawada , Nathan Bossart , PostgreSQL Hackers , shveta malik 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 Tue, Sep 3, 2024 at 3:01=E2=80=AFPM shveta malik wrote: > > > 1) > I see that ReplicationSlotAlter() will error out if the slot is > invalidated due to timeout. I have not tested it myself, but do you > know if slot-alter errors out for other invalidation causes as well? > Just wanted to confirm that the behaviour is consistent for all > invalidation causes. I was able to test this and as anticipated behavior is different. When slot is invalidated due to say 'wal_removed', I am still able to do 'alter' of that slot. Please see: Pub: slot_name | failover | synced | inactive_since | invalidation_reason -------------+----------+--------+----------------------------------+------= --------------- mysubnew1_1 | t | f | 2024-09-04 08:58:12.802278+05:30 | wal_removed Sub: newdb1=3D# alter subscription mysubnew1_1 disable; ALTER SUBSCRIPTION newdb1=3D# alter subscription mysubnew1_1 set (failover=3Dfalse); ALTER SUBSCRIPTION Pub: (failover altered) slot_name | failover | synced | inactive_since | invalidation_reason -------------+----------+--------+----------------------------------+------= --------------- mysubnew1_1 | f | f | 2024-09-04 08:58:47.824471+05:30 | wal_removed while when invalidation_reason is 'inactive_timeout', it fails: Pub: slot_name | failover | synced | inactive_since | invalidation_reason -------------+----------+--------+----------------------------------+------= --------------- mysubnew1_1 | t | f | 2024-09-03 14:30:57.532206+05:30 | inactive_timeout Sub: newdb1=3D# alter subscription mysubnew1_1 disable; ALTER SUBSCRIPTION newdb1=3D# alter subscription mysubnew1_1 set (failover=3Dfalse); ERROR: could not alter replication slot "mysubnew1_1": ERROR: can no longer get changes from replication slot "mysubnew1_1" DETAIL: The slot became invalid because it was inactive since 2024-09-04 08:54:20.308996+05:30, which is more than 0 seconds ago. HINT: You might need to increase "replication_slot_inactive_timeout.". I think the behavior should be same. thanks Shveta