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 1tx7qt-003GwZ-6Y for pgsql-general@arkaria.postgresql.org; Tue, 25 Mar 2025 17:14:11 +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 1tx7qr-007HZn-MD for pgsql-general@arkaria.postgresql.org; Tue, 25 Mar 2025 17:14:09 +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 1tx7qr-007HZf-BL for pgsql-general@lists.postgresql.org; Tue, 25 Mar 2025 17:14:09 +0000 Received: from smtp103.iad3a.emailsrvr.com ([173.203.187.103]) by makus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tx7qp-00159q-2s for pgsql-general@postgresql.org; Tue, 25 Mar 2025 17:14:08 +0000 X-Auth-ID: xof@thebuild.com Received: by smtp37.relay.iad3a.emailsrvr.com (Authenticated sender: xof-AT-thebuild.com) with ESMTPSA id 872ED65F1; Tue, 25 Mar 2025 13:14:06 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.1\)) Subject: Re: Replication slot WAL reservation From: Christophe Pettus In-Reply-To: Date: Tue, 25 Mar 2025 10:13:35 -0700 Cc: pgsql-general@postgresql.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Phillip Diffley X-Mailer: Apple Mail (2.3776.700.51.11.1) X-Classification-ID: 6d5b2f84-18a9-41a3-b6c0-d5cc286c758a-1-1 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Missed this question! > On Mar 25, 2025, at 09:56, Phillip Diffley = wrote: > But when processing data from a replication slot, we confirm rows that = have been processed and can be deleted from the WAL based on the LSN = (eg. with pg_replication_slot_advance). How does postgres identify what = parts of the WAL can be freed? Basically, if no part of the system "needs" a particular LSN position, = the segments that include that LSN position and earlier can be free. The various things that can "need" a particular LSN point are: 1. Replication slots, if the other side has not confirmed that it has = received it (under whatever synchronous commit rules that slot is = operating under). 2. The wal_keep_size setting. 3. The max_wal_size setting. 4. The archive_command, if a WAL segment hasn't been successfully = archived yet. One thing to remember is that the WAL does *not* contain contiguous = blocks of operations for a single transaction. The operations are = written to the WAL by every session as they do operations, so the WAL is = a jumble of different transactions. One of the jobs of the logical = replication framework is to sort that out so it can present only the = operations that belong to committed transactions to the output plugin. = (This is why there's an internal structure called the "reorder buffer": = it reorders WAL operations into transaction blocks.)=