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 1snWsg-004DWr-Gi for pgsql-hackers@arkaria.postgresql.org; Mon, 09 Sep 2024 05:24:07 +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 1snWsg-006O0R-0y for pgsql-hackers@arkaria.postgresql.org; Mon, 09 Sep 2024 05:24:06 +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.94.2) (envelope-from ) id 1snWsf-006O0J-Lk for pgsql-hackers@lists.postgresql.org; Mon, 09 Sep 2024 05:24:05 +0000 Received: from mail-wr1-x435.google.com ([2a00:1450:4864:20::435]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1snWsc-000FIk-Ao for pgsql-hackers@lists.postgresql.org; Mon, 09 Sep 2024 05:24:05 +0000 Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-374c7e64b60so2269431f8f.2 for ; Sun, 08 Sep 2024 22:24:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725859443; x=1726464243; 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=PyAwF2veSyhK5rdbOoEDOkMi/47jbncoLIsWuuwiPrw=; b=DsyI43szGrbTRS74X1B8Bo1kRtAWw2bNDtzpf8rPaXMmjYobJUfVz73O8tGmLHe3xt bAPhHkFrNgOz287XZ0aQhh7Buut0KN51Uusfr8KhUXxSBaS1qSIvNz1u2jBvP8brFm75 kTAm1Y2JVw/5nPctF86v+cpATQl8Gm7Cr8wOKuoVgJLv8ruGqhOiRQhvay9WmH38Y7NR hu25LfFJEI0g4wQCsXSSJoG+w9NatrGkMUxUAECVcoGrjNJaJLntNJRtUu+Uk6jbu6ga T1IMuroi+6LTPMNvlLqm6yin/R7O2rtUPB8rwHlxdFkmJu61t8RB/wfZzeI4wf+oiNXM i29Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725859443; x=1726464243; 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=PyAwF2veSyhK5rdbOoEDOkMi/47jbncoLIsWuuwiPrw=; b=Ue9WqyEgEJ/hdE4MbLamVe5ArB7zooy6Yu8ekZyWCXafhSpBEp+EnZn9Cazz8x99N4 8l9NogBwzLjpbMVruNzI0J00SBHZXqkFi0/S/4h4UoNVs8I0EHVsc5wru8ObX/17n9H5 5r8V3i/LyJn6G33R9WuWrjLZcgz8GU2MJx6bN8514C7KKQqd7gitaDfdSlGAxaAoGZXa yc4x06i5ZmbyM2I3hg6wfCOMO8Kp83F6NItpRM98CBqcyY9am1gw5Gb7Bn6pOEeCzHaQ 6pzYxLxgNIERGxGzBc9OQrrAkWhap/hA4gSavxnWftzKjjhVEvy5dP5Y1OWYpGlWqDZU EJeg== X-Forwarded-Encrypted: i=1; AJvYcCU5n2sTYQgs7M+ZlP0FlPd/2ys8P6y7WM7yk+kpvjTnadOprj3rqT/wEPksABPT6Z/DANLEe1JfrfKZHhc2@lists.postgresql.org X-Gm-Message-State: AOJu0Yx4xuawv7E+sO5sN05Hd7zYBGwPYMTH9Ds+okYeswW6YHn28CNf Vh2eIN+TbppGiz9SL3lPRXvkxbWt+mAA2FbFhQ0BWrzNc4Js2e2DfocihsQCbqIVWWzrg/EQBsK k1NJTvojwq0xzhbZQJ32YDf2wPZ8= X-Google-Smtp-Source: AGHT+IEOIhrMFkaFqqArswk2bzpxboRmTYZcNUEeJt/lZYY02wtUjLIfvTPpZarPTX8b6VEkVGC3UDObAUqy6inyJOI= X-Received: by 2002:adf:f4c2:0:b0:374:c022:fa76 with SMTP id ffacd0b85a97d-378896a93ebmr6849992f8f.37.1725859442009; Sun, 08 Sep 2024 22:24:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Mon, 9 Sep 2024 10:53:50 +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 Sun, Sep 8, 2024 at 5:25=E2=80=AFPM Bharath Rupireddy wrote: > > > Please find the v45 patch. Addressed above and Shveta's review comments [= 1]. > Thanks for the patch. Please find my comments: 1) src/sgml/config.sgml: + Synced slots are always considered to be inactive because they don't perform logical decoding to produce changes. It is better we avoid such a statement, as internally we use logical decoding to advance restart-lsn, see 'LogicalSlotAdvanceAndCheckSnapState' called form slotsync.c. 2) src/sgml/config.sgml: + disables the inactive timeout invalidation mechanism + Slot invalidation due to inactivity timeout occurs during checkpoint. Either have 'inactive' at both the places or 'inactivity'. 3) slot.c: +static bool InvalidatePossiblyObsoleteSlot(ReplicationSlotInvalidationCaus= e cause, + ReplicationSlot *s, + XLogRecPtr oldestLSN, + Oid dboid, + TransactionId snapshotConflictHorizon, + bool *invalidated); +static inline bool SlotInactiveTimeoutCheckAllowed(ReplicationSlot *s); I think, we do not need above 2 declarations. The code compile fine without these as the usage is later than the definition. 4) + /* + * An error is raised if error_if_invalid is true and the slot has been + * invalidated previously. + */ + if (error_if_invalid && s->data.invalidated =3D=3D RS_INVAL_INACTIVE_TIME= OUT) The comment is generic while the 'if condition' is specific to one invalidation cause. Even though I feel it can be made generic test for all invalidation causes but that is not under scope of this thread and needs more testing/analysis. For the time being, we can make comment specific to the concerned invalidation cause. The header of function will also need the same change. 5) SlotInactiveTimeoutCheckAllowed(): + * Check if inactive timeout invalidation mechanism is disabled or slot is + * currently being used or server is in recovery mode or slot on standby i= s + * currently being synced from the primary. + * These comments say exact opposite of what we are checking in code. Since the function name has 'Allowed' in it, we should be putting comments which say what allows it instead of what disallows it. 6) + * Synced slots are always considered to be inactive because they don't + * perform logical decoding to produce changes. + */ +static inline bool +SlotInactiveTimeoutCheckAllowed(ReplicationSlot *s) Perhaps we should avoid mentioning logical decoding here. When slots are synced, they are performing decoding and their inactive_since is changing continuously. A better way to make this statement will be: We want to ensure that the slots being synchronized are not invalidated, as they need to be preserved for future use when the standby server is promoted to the primary. This is necessary for resuming logical replication from the new primary server. 7) InvalidatePossiblyObsoleteSlot() we are calling SlotInactiveTimeoutCheckAllowed() twice in this function. We shall optimize. At the first usage place, shall we simply get timestamp when cause is RS_INVAL_INACTIVE_TIMEOUT without checking SlotInactiveTimeoutCheckAllowed() as IMO it does not seem a performance critical section. Or if we retain check at first place, then at the second place we can avoid calling it again based on whether 'now' is NULL or not. thanks Shveta