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 1slPsj-007XFQ-E5 for pgsql-hackers@arkaria.postgresql.org; Tue, 03 Sep 2024 09:31:26 +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 1slPsi-009Upv-Gy for pgsql-hackers@arkaria.postgresql.org; Tue, 03 Sep 2024 09:31:24 +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 1slPsi-009Uph-7a for pgsql-hackers@lists.postgresql.org; Tue, 03 Sep 2024 09:31:24 +0000 Received: from mail-wm1-x32a.google.com ([2a00:1450:4864:20::32a]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1slPsf-000QcR-Ra for pgsql-hackers@lists.postgresql.org; Tue, 03 Sep 2024 09:31:23 +0000 Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-42bb9d719d4so37302285e9.3 for ; Tue, 03 Sep 2024 02:31:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725355879; x=1725960679; 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=MrUGv/b86YoiTxRxfLt+Nm7+IDSjrv7QkVzAT8kAZHc=; b=aTQCxNlLnNp0TY1aIIFXIWRNuF2sYys8jwqMAEk1ygKP8d4IfzHNfq5AdDa18KCXjT oWhSW0NrEtV5yfGvKylB8THdrnbLQ8Z4YbI8vkMJdXBgdDkJnUPkly+R3icFE5ajaJB4 skE0TrLmWdy42BuvTShlvWKzNm2UdyHjW4T0psKXI0R7jqnY5yNN/TPE5i0UmzP25eUV 1AR+Fkpyiw6BeSPsAm0UFBvE+hMS9LnuAq4qaUwWQoVc2FSMr3C10bJ5M3NkVnETYuUO 7QtM2pghruPB0w+8CDQ7laZUH4bl8rjdGGXICkrTqIkk/c1J9vIbCt64O1cBZj6cE691 S3Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725355879; x=1725960679; 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=MrUGv/b86YoiTxRxfLt+Nm7+IDSjrv7QkVzAT8kAZHc=; b=CZpcna6sZ3qLHhd8rpjlbjWbcon9r1vzcEO05ucNgeTd9XQ/+0rmuSUnb1eSdQ6xC/ cW5ntaJOfsYZoPOaL8nrXEr5A9JtKXNzZXW5xADeBYnlos8GlFXfGCeNRdzBugPEJUqi CHBTVKvv8IbnzoYIpq1nCj9TL1eMNGxppX+vlD8Oj1xndioA1QMrBbCNli1j3yhiBjBD 8R3+ny1F+vQpScmZX5h4HkBfglr471rXgqXbySE4pL1ZTnqWqKhE7N6aiQugECiJOK0m 2CxL6U6bt9rgWnJ6YmCcMxR4zOPIebcu5LbVeDHe680fOqCgks7MX3c8zGiHtlla39sp 2PDg== X-Forwarded-Encrypted: i=1; AJvYcCWcOKKHCjw92QgFmmsf1WOEN7IXV8esusKTX0/fPcCPUv/whz8jUMlGEclCzC38xcpHXGrjVr7wgsEzd/pL@lists.postgresql.org X-Gm-Message-State: AOJu0Yx8flos6iVaWd+x2nfa/sjJc0sAib8wqhfuHa5K8nvHvpBhY/ng n5K84NeNApCNrw69m61Ur0u8QTsDGxOQfUZJlQdphlCor03q25lYCKAHUn0ujGXiQu/Wn1dOf7q KzzaHNafP8sE5gOlxMwDRDv13K169bb6y X-Google-Smtp-Source: AGHT+IGsW7ziUya2J2U3e594ZiVhL5Xhb+gIM2Jp9sq1aP62RFkAmlbm7tQ8nQL3sVPKzUR/L+qAlmw8lvQM+M+u8so= X-Received: by 2002:adf:f2c7:0:b0:374:c0c9:d178 with SMTP id ffacd0b85a97d-374ecc67ba1mr1973571f8f.9.1725355878748; Tue, 03 Sep 2024 02:31:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Tue, 3 Sep 2024 15:01:06 +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 Sat, Aug 31, 2024 at 1:45=E2=80=AFPM Bharath Rupireddy wrote: > > Hi, > > > Please find the attached v44 patch with the above changes. I will > include the 0002 xid_age based invalidation patch later. > Thanks for the patch Bharath. My review and testing is WIP, but please find few comments and queries: 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. 2) When a slot is invalidated, and we try to use that slot, it gives this msg: ERROR: can no longer get changes from replication slot "mysubnew1_2" DETAIL: The slot became invalid because it was inactive since 2024-09-03 14:23:34.094067+05:30, which is more than 600 seconds ago. HINT: You might need to increase "replication_slot_inactive_timeout.". Isn't HINT misleading? Even if we increase it now, the slot can not be reused again. 3) When the slot is invalidated, the' inactive_since' still keeps on changing when there is a subscriber trying to start replication continuously. I think ReplicationSlotAcquire() keeps on failing and thus Release keeps on setting it again and again. Shouldn't we stop setting/chnaging 'inactive_since' once the slot is invalidated already, otherwise it will be misleading. postgres=3D# select failover,synced,inactive_since,invalidation_reason from pg_replication_slots; failover | synced | inactive_since | invalidation_reason ----------+--------+----------------------------------+--------------------= - t | f | 2024-09-03 14:23:.. | inactive_timeout after sometime: failover | synced | inactive_since | invalidation_reason ----------+--------+----------------------------------+--------------------= - t | f | 2024-09-03 14:26:..| inactive_timeout 4) src/sgml/config.sgml: 4a) + A value of zero (which is default) disables the timeout mechanism. Better will be: A value of zero (which is default) disables the inactive timeout invalidation mechanism . or A value of zero (which is default) disables the slot invalidation due to the inactive timeout mechanism. i.e. rephrase to indicate that invalidation is disabled. 4b) 'synced' and inactive_since should point to pg_replication_slots: example: pg_replication_slots.synced 5) src/sgml/system-views.sgml: + ..the slot has been inactive for longer than the duration specified by replication_slot_inactive_timeout parameter. Better to have: ..the slot has been inactive for a time longer than the duration specified by the replication_slot_inactive_timeout parameter. thanks Shveta