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.98.2) (envelope-from ) id 1x9ytT-00000002Nrp-3YZ9 for pgsql-hackers@arkaria.postgresql.org; Fri, 25 Sep 2026 05:54:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.98.2) (envelope-from ) id 1x9ytT-0000000GaU1-0UrH for pgsql-hackers@arkaria.postgresql.org; Fri, 25 Sep 2026 05:54:47 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1x9ytS-0000000GaTt-3XID for pgsql-hackers@lists.postgresql.org; Fri, 25 Sep 2026 05:54:46 +0000 Received: from mail-wr2-x10.google.com ([2a00:1450:4864:30::10]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1x9ytQ-00000001BVb-1a3E for pgsql-hackers@lists.postgresql.org; Fri, 25 Sep 2026 05:54:46 +0000 Received: by mail-wr2-x10.google.com with SMTP id ffacd0b85a97d-482f6350f89so282267f8f.3 for ; Thu, 24 Sep 2026 22:54:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790315683; x=1790920483; darn=lists.postgresql.org; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to:content-type; bh=N/7SMrqxYf0v00TnUdrjPRwbSfbPr7Y4M4prQume/dM=; b=fOwl3Ai1IaHMb6S795rhLLV+KaE+twpT1D8e51WPDnrSYaKV22EK8F0Hela/dhWyrT WffRiI4MdM3Ini4WboaQJ4LqCfMoAW5xdi62pHrPIdwWHbmzrhbKZMryElSxGENXb+0d 8IdQC68Rv+tIZbukE+nr9UHRwpFszHK54ohUGgTh2lmXCriPXfayEfgYW6ycT+WDFWwC EtXaAvOz5PwWkoJ2L4Vu9RrsNhiNLYGf0EDIVtIsuFraeAZ7WXiV78SLLqzGnCjtgVwl L+JQXE42t88RdQcudXSxrOdeU0TGH48kdyXUZd/SZ7/UT7i36Y2v0tYCyCr6G8hCrvin j+Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790315683; x=1790920483; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=N/7SMrqxYf0v00TnUdrjPRwbSfbPr7Y4M4prQume/dM=; b=fSFKxvT8BsRKXks14lEQxIJiP2z27ofME/SHtemULDx0iN6tSnKs+XS9aX1Bzz/wJi u3/DqlDn0UFXZWjSyBF3rDE8hUTo9AMgIk8YRVP0YSleQfyErn4TIXp6Bko01DPMzdeJ lF5qwaop4v49BnHYTjUQKTB3ghlYsPw1nIAP9v1raMbgc82qtF1ykz6stHJ6jB/JEr28 NZp07f2GYewzyHCuiq2qk5qaSEsoTqj3jShQrst8uoB4yQ+3AO+R0xgiNUiTL/Vp+Pn0 eoZ6SVUXn2l7Fiuvfp0FFkFLzXHgKRowI5ETEp60YTLCPzUCXa8oijlkR+5dkDcekwAx T/MA== X-Forwarded-Encrypted: i=1; AKwUvBxQLPM//KZqVZI4G2IFnmtIyET0qMqAdGJJJqFvPwBcPf43naj+RrFS2CI/osJdgPEvKQDdOSmPMJ2AbwRA@lists.postgresql.org X-Gm-Message-State: AFuF++nfZAOncDGqcQ5yZoxzxe45MUp4LEt65ejKv4Y+rPb/c3/qUYhb O6xHVPAZvGjyvk0EA7UGd21Mq+7R9n2jtzF18zY1AfsYDEVTRexkDubq X-Gm-Gg: AYBFou0jomykJpbhq7JITbLk9oD6lFCscTzIV/cq0y06w7PHXBxjMvPqo7sjrtowqLx w6OrdqrJZKZ0zxDX/9yAzgRV7toUrG0WUiGeGqaQ/vwBdZJubEinIiI4p5RRW1zdi2pRxu6Zy4o jW5/quXtc5tTtNxMJxYVuIYElCKxlPIR8G+JpeZ+BtCB7X9iJqCOZ9G65PqCZhpjdtRinqSt9iq e+VLp5ohdQo23P5M4ZSM80nwuN4eRAFj2xKT4/f0mrDg4aa/aXlDYStPmIU24pr+s0jaT8SYEVO y7jl+wr7Msk/xhTWtUub0a2vjt1p5jOSiVLSYddUdZFw3Zy2vrmfUOjS2C4KGsz3V7YMBtUSmwy 6L/8C4Lat4gNUJz/5aqm4hWzb3QlkNUmOUBfi8J/TzWXXnebwFIRcvZJeSViIjj8fb27zI6ooyH GLRz0VrY3VvJ/ehh8ahS5h/MsvIPQ/RMMgKsbFba9+FMIdC6kYQ+ObMybWCnSRmZVuQd0poyuKS BLYj5YvewgwD4tvQRGTYLrU4/YVfZZjTHWsdBY251+K8bCXcqEs5ed4Rg== X-Received: by 2002:a05:600c:5490:b0:49f:edeb:6445 with SMTP id 5b1f17b1804b1-49ff06bd97fmr19427095e9.11.1790315683189; Thu, 24 Sep 2026 22:54:43 -0700 (PDT) Received: from bdtpg (ec2-15-237-197-144.eu-west-3.compute.amazonaws.com. [15.237.197.144]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49ff069d071sm38706365e9.5.2026.09.24.22.54.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Sep 2026 22:54:42 -0700 (PDT) Date: Fri, 25 Sep 2026 05:54:41 +0000 From: Bertrand Drouvot To: shveta malik Cc: JoongHyuk Shin , Amit Kapila , Rui Zhao , pgsql-hackers@lists.postgresql.org Subject: Re: Persist slot invalidations before publishing them Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On Fri, Sep 25, 2026 at 09:38:27AM +0530, shveta malik wrote: > On Thu, Sep 24, 2026 at 3:11 PM Bertrand Drouvot > wrote: > > > > Thanks for addressing comments. A few concerns on 001: Thanks for looking at it! > 1) > > In SaveSlotToPath(), should we add an 'Assert(cp.slotdata.restart_lsn > == InvalidXLogRecPtr)' at the end for the 'if (clear_restart_lsn)' > case? > > slot->data.invalidated = invalidation_cause; > if (clear_restart_lsn) > + { > + Assert(cp.slotdata.restart_lsn == InvalidXLogRecPtr); > slot->data.restart_lsn = InvalidXLogRecPtr; > + } > > While slot->last_saved_restart_lsn correctly inherits > cp.slotdata.restart_lsn on the next line, adding this Assert > guarantees that the removed logic from > InvalidatePossiblyObsoleteSlot() was successfully compensated for in > the on-disk struct before we propagate it to shared memory. It is not > mandatory, but it would be good to have. I’m not sure this assertion adds much, since cp.slotdata.restart_lsn is explicitly cleared above and is not modified afterward. > 2) > + Assert(update_inactive_since || slot->data.persistency == RS_PERSISTENT); > > In ReplicationSlotReleaseInternal(), I didn’t quite understand the > reasoning behind above Assert. Does this mean that when the caller > passes update_inactive_since=true, the slot can even be temporary, > whereas if we are not updating inactive_since, the slot must be > persistent? Yes. In fact, with update_inactive_since=true it can also be ephemeral, since ReplicationSlotRelease() uses that value for the ordinary release path. This is not specific to slotsync. The false case is introduced by 0001 and is only used to preserve inactive_since when rolling back ownership of an inactive persistent slot. Maybe the following comment would make that clearer? " /* * Skipping the inactive_since update is only needed when undoing the * internal acquisition of an inactive persistent slot after an ERROR. */ " > 3) > Another doubt I have is that with above Assert, when > update_inactive_since is TRUE, we are even allowing RS_EPHEMERAL > slots. However, ReplicationSlotPersistInvalidation() explicitly > disallows them in patch002 with: > > Assert(slot->data.persistency != RS_EPHEMERAL); > > Both checks are not in sync. I think they apply to different scopes. ReplicationSlotReleaseInternal() is the general release implementation, so update_inactive_since=true imposes no persistency restriction. In particular, an ephemeral slot is dropped by that path. ReplicationSlotPersistInvalidation() has a narrower contract and is only intended for persistent or temporary slots. That said, maybe its Assert could express all the supported combinations more clearly? " Assert(slot->data.persistency == RS_PERSISTENT || (slot->data.persistency == RS_TEMPORARY && update_inactive_since)); " Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com