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 1snrGj-006XK0-Ka for pgsql-hackers@arkaria.postgresql.org; Tue, 10 Sep 2024 03:10:18 +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 1snrGj-005CGA-9g for pgsql-hackers@arkaria.postgresql.org; Tue, 10 Sep 2024 03:10:17 +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 1snrGi-005CG0-Tx for pgsql-hackers@lists.postgresql.org; Tue, 10 Sep 2024 03:10:16 +0000 Received: from mail-lj1-x233.google.com ([2a00:1450:4864:20::233]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1snrGe-000P6B-VW for pgsql-hackers@lists.postgresql.org; Tue, 10 Sep 2024 03:10:16 +0000 Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-2f74e468baeso60548591fa.2 for ; Mon, 09 Sep 2024 20:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725937813; x=1726542613; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8zTxEjz6fm+jk2wgE7BRXIPW8CbZezdKiy2AoTGioFw=; b=M99foNiyzyNcmyD9FKyrP5B2yKBSzWAqGObJZyAic56d79wj1TOT3MmCTk8CoNLucK /K9OBEEVFIm4CpapiPuNFkdjXPsaE5os3Xu/VfHSe4ohLPXRyykPf3e6OoBexAdUacmp 4/ifTfmhq89Q+jl9K83UPCwUlyCBrU1e8LdGe0JXWVN03Dx/+FLSdTRyGcgRRPT55wAw jKv8puLh5I/+eLhpLDaK9jMA85Ak4V2TyODMguKDPICJzMOPxDP4Ftx1DC5kNUIeXKc0 p7aikfmK82rp/C7kCKWRieBGoYx0Uyquw8nXe7lJAQJ02TbHwBSYKqIA+r+I9JJ2f/a1 wdWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725937813; x=1726542613; h=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=8zTxEjz6fm+jk2wgE7BRXIPW8CbZezdKiy2AoTGioFw=; b=qc5tZGYepBCJGXYzb8f0/6Td5l3C1oiRNBFD+HNKPGT+4pBKhHsXQyrhQp5djy8f7A +LEA92NR8w1s4mvA7iKe9eRF8gBqXg7gzl7WfKK1OxL4JGyvryder0irMG9buTdntTAm IhY+HXHaRvNDNroPaWgleY57tF9bWmFl2KbFHWFwS+ZDc61HljozTXgiuKW1ZkmCGB2b yXwHC1GLkfRlreq0tZ/159HESu8LDBmcYRK9/9jYbyeTpJ9Ty4ihCETq6qyAoAPoI53J lnAIIDvwgY4W9yMqdjfBWKTMaaKijAiMQoam/sE0z+37inhbiHb0DNjL7FjkQeqw3Hun i+hg== X-Gm-Message-State: AOJu0Yygwszq/7+s2dBNX+ShV1bcn0Z1f5weimRg+W6DxxliSG3m8VNm ZwBLk8gcKfHvF5Fq1HHSH3HC5HnwAd0qcIgzWkhtRNQlb7DG3ZzyviLYp22L8z3zsCQNROKHKJZ PEUJh5rf9ed5EVCiw+vKh6tPrPN2Pj/FUUPI= X-Google-Smtp-Source: AGHT+IFKQrcQCKK6VT+nQ4gjbphCyzhXRD9nsYsAadN4SAv911pOqcAg5AxR/8VFMC5wcB5ptRiqR7nS2tLjnSOfIg8= X-Received: by 2002:a2e:a9a6:0:b0:2f7:5239:5d9b with SMTP id 38308e7fff4ca-2f75b87e246mr75287671fa.4.1725937812565; Mon, 09 Sep 2024 20:10:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Smith Date: Tue, 10 Sep 2024 13:09:45 +1000 Message-ID: Subject: Re: Disallow altering invalidated replication slots To: Bharath Rupireddy Cc: PostgreSQL Hackers Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, here are some review comments for patch v1. ====== Commit message 1. ALTER_REPLICATION_SLOT on invalidated replication slots is unnecessary as there is no way... suggestion: ALTER_REPLICATION_SLOT for invalid replication slots should not be allowed because there is no way... ====== 2. Missing docs update Should this docs page [1] be updated to say ALTER_REPLICATION_SLOT is not allowed for invalid slots? ====== src/backend/replication/slot.c 3. + if (MyReplicationSlot->data.invalidated != RS_INVAL_NONE) + ereport(ERROR, + errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE), + errmsg("cannot alter replication slot \"%s\"", name), + errdetail("This replication slot was invalidated due to \"%s\".", + SlotInvalidationCauses[MyReplicationSlot->data.invalidated])); + I thought including the reason "invalid" (e.g. "cannot alter invalid replication slot \"%s\"") in the message might be better, but OTOH I see the patch message is the same as an existing one. Maybe see what others think. ====== src/test/recovery/t/035_standby_logical_decoding.pl 3. There is already a comment about this test: ################################################## # Recovery conflict: Invalidate conflicting slots, including in-use slots # Scenario 1: hot_standby_feedback off and vacuum FULL # # In passing, ensure that replication slot stats are not removed when the # active slot is invalidated. ################################################## IMO we should update that "In passing..." sentence to something like: In passing, ensure that replication slot stats are not removed when the active slot is invalidated, and check that an error occurs when attempting to alter the invalid slot. ====== [1] docs - https://www.postgresql.org/docs/devel/protocol-replication.html Kind Regards, Peter Smith. Fujitsu Austalia