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 1qpUIG-005vVM-ND for pgsql-hackers@arkaria.postgresql.org; Sun, 08 Oct 2023 13:58:04 +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 1qpUID-006yhd-DY for pgsql-hackers@arkaria.postgresql.org; Sun, 08 Oct 2023 13:58:02 +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 1qpUID-006yhV-3c for pgsql-hackers@lists.postgresql.org; Sun, 08 Oct 2023 13:58:02 +0000 Received: from smtp.burggraben.net ([2a01:4f8:140:510a::3]) by magus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qpUIA-000vsE-Lw for pgsql-hackers@lists.postgresql.org; Sun, 08 Oct 2023 13:58:01 +0000 Received: from elch.exwg.net (elch.exwg.net [IPv6:2001:470:7120:1:127b:44ff:fe4f:148d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "elch.exwg.net", Issuer "R3" (not verified)) by smtp.burggraben.net (Postfix) with ESMTPS id 69D86C0030C; Sun, 8 Oct 2023 15:57:55 +0200 (CEST) Received: by elch.exwg.net (Postfix, from userid 1000) id E5E9D3AB03; Sun, 8 Oct 2023 15:57:54 +0200 (CEST) Date: Sun, 8 Oct 2023 15:57:54 +0200 From: Christoph Moench-Tegeder To: Fabrice Chapuis Cc: PostgreSQL Hackers Subject: Re: wal recycling problem Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.2.12 (2023-09-09) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ## Fabrice Chapuis (fabrice636861@gmail.com): > From a conceptual point of view I think that specific wals per subscription > should be used and stored in the pg_replslot folder in order to avoid > working directly on the wals of the instance. > What do you think about this proposal? I think that would open a wholly new can of worms. The most obvious point here is: that WAL is primarily generated for the operation of the database itself - it's our kind of transaction log, or "Redo Log" in other systems' lingo. Replication (be it physical or logical) is a secondary purpose (an obvious and important one, but still secondary). How would you know which part of WAL is needed for any specific replication slot? You'd have to decode and filter it, and already you're back at square one. How would you handle multiple replications for the same table (in the same publication, or even over multiple (overlapping) publications) - do you multiply the WAL? For now, we have "any replication using replication slots, be it logical or physical replication, retains WAL up to max_slot_wal_keep_size (or "unlimited" if not set - and on PostgreSQL 12 and before); and you need to monitor the state of your replication slots", which is a totally usabe rule, I think. Regards, Christoph -- Spare Space