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 1roqPJ-003gaO-Bi for pgsql-hackers@arkaria.postgresql.org; Mon, 25 Mar 2024 19:54:57 +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 1roqPF-007PBa-Ln for pgsql-hackers@arkaria.postgresql.org; Mon, 25 Mar 2024 19:54:54 +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 1roqPF-007PBS-85 for pgsql-hackers@lists.postgresql.org; Mon, 25 Mar 2024 19:54:53 +0000 Received: from mail-il1-x12c.google.com ([2607:f8b0:4864:20::12c]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1roqP7-006O72-Rs for pgsql-hackers@lists.postgresql.org; Mon, 25 Mar 2024 19:54:52 +0000 Received: by mail-il1-x12c.google.com with SMTP id e9e14a558f8ab-366b3b6d527so17341025ab.0 for ; Mon, 25 Mar 2024 12:54:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711396486; x=1712001286; darn=lists.postgresql.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=+SoVePx93lif4lnbTIl5MAkkNnLKPLec+flg5UlbWik=; b=FF5VR2x4JQTH/HkLkqv0vZ1wX3VcGVtZTlng6lU4YmafEcvEkwCq9RHKImFWNS406q 5cOsQvKHhTCFvZluAK9f9SpgEpAkaOZRXT2cDOkkTAFGG9DmcoVbAuOhRMPVxlmWLQQQ +O/OdEXAZn9pe5VvyhgmTt6Ty7XuI9hDAoF5Hq1o4tav5vce7QvihKVRFbnNJ51k+ARF es6CXjoCzD2qqnWkn0gRqPbZX3IrSzdaW+SK2hSKeOXJ6fqdXV9H8onfdLJgMFL9aPMw dNBMtfDRjCP1c08sQFZhUqZTpuI43E34rutiX4wQIMfgJhs1jRJgTuyUixMUe8OVWnoe f/kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711396486; x=1712001286; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=+SoVePx93lif4lnbTIl5MAkkNnLKPLec+flg5UlbWik=; b=tmnSokD6gg8uyOe4eQpngCD3+erGDD6F2A+u7Yz3/o47piB+BN/yodFjMkxzYfC6h7 Lmk4ZdpjElv3EGRUspekb8/zsHTcZwC2wi4bK/qRQr6lHCz6KZ7YcXKG2vbGwCGepWfD YiDuoZUDOrYMUPSEdQXGWnMgTtN9V7oILH01nMoxYqsG7NYL9E0XvB91meDaSqwTNX7c 48z/22oPYuBhs5gzJtNaEOJLFN10GqjWzNYhmLyoDIyUEf88jzm1ZfpvYBt66BL9KJPP MmJEZstRZXrWbw6j34crxmcODOLAoHCGkkECWwiBVk4DESVajY1ZaKcDCOBRRmo+Rc6+ VovQ== X-Forwarded-Encrypted: i=1; AJvYcCUYd8ieG2bPhwn2V2150lZJrWRJrfK+zrA6t495vxfPn/5f7bqQarcwxHRWUXVqbvhym9NI3blAtZAq6gfK4pch43kEhNUcJ2ZE2atD91RoDdIU X-Gm-Message-State: AOJu0YwvFfFZ9KmkavasznzUfKa09W+IO66LbYSxlRbDC2iGp/eI51A7 AZ+ptoBKWixIzr0A80SBwKFdxjF9ha4qpRieh4Vyl8UtP7ZS1bCR X-Google-Smtp-Source: AGHT+IE5LlahdBXXGHoxlesLI/kxNquTkf6tesVactv7iNIoc6DHdgtW8wGm3++7YynLURF5BudcBA== X-Received: by 2002:a05:6e02:17c9:b0:368:8a16:509c with SMTP id z9-20020a056e0217c900b003688a16509cmr4768394ilu.1.1711396485847; Mon, 25 Mar 2024 12:54:45 -0700 (PDT) Received: from nathanxps13 (162-195-168-172.lightspeed.stlsmo.sbcglobal.net. [162.195.168.172]) by smtp.gmail.com with ESMTPSA id h5-20020a92c085000000b003689833dae7sm370969ile.87.2024.03.25.12.54.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Mar 2024 12:54:45 -0700 (PDT) Date: Mon, 25 Mar 2024 14:54:43 -0500 From: Nathan Bossart To: Bharath Rupireddy Cc: Amit Kapila , Bertrand Drouvot , PostgreSQL Hackers Subject: Re: Introduce XID age and inactive timeout based replication slot invalidation Message-ID: <20240325195443.GA2923888@nathanxps13> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I apologize that I haven't been able to keep up with this thread for a while, but I'm happy to see the continued interest in $SUBJECT. On Sun, Mar 24, 2024 at 03:05:44PM +0530, Bharath Rupireddy wrote: > This commit particularly lets one specify the inactive_timeout for > a slot via SQL functions pg_create_physical_replication_slot and > pg_create_logical_replication_slot. Off-list, Bharath brought to my attention that the current proposal was to set the timeout at the slot level. While I think that is an entirely reasonable thing to support, the main use-case I have in mind for this feature is for an administrator that wants to prevent inactive slots from causing problems (e.g., transaction ID wraparound) on a server or a number of servers. For that use-case, I think a GUC would be much more convenient. Perhaps there could be a default inactive slot timeout GUC that would be used in the absence of a slot-level setting. Thoughts? -- Nathan Bossart Amazon Web Services: https://aws.amazon.com