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 1tDt3L-003qjT-TR for pgsql-hackers@arkaria.postgresql.org; Wed, 20 Nov 2024 22:20:03 +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 1tDt3K-009iEA-IF for pgsql-hackers@arkaria.postgresql.org; Wed, 20 Nov 2024 22:20:02 +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 1tDt3J-009iDy-N1 for pgsql-hackers@lists.postgresql.org; Wed, 20 Nov 2024 22:20:02 +0000 Received: from relay5-d.mail.gandi.net ([2001:4b98:dc4:8::225]) by makus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tDt3G-002wpH-Iu for pgsql-hackers@lists.postgresql.org; Wed, 20 Nov 2024 22:20:00 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id AD07E1C0003 for ; Wed, 20 Nov 2024 22:19:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vondra.me; s=gm1; t=1732141193; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bMRwZpzPDTUn/bJGDa6WmIups/muXjvRPD553sceWDU=; b=gkJzHphsQvLENkMlDvPr8ZVefTpLSJp4JevRmN8ZYRDXkXx6Kq+zFKgTBzK9UoxU2MGnUb 9qLUPRy774WOIhWNfImqysYPmxsCKMsjksJGtC3wXb7UkP6XrVnCTcxJXzBlFSgtmTv7ny 8cm1q8czhICfajuhifEKC8lw7gVE1VLKJg04DgJA6mgXJIk7ftwRy1y+LI8LP5dRlAurNE iIxU4Ht66UyppXTvCYtpJBQAgZZbe3M3GttKbf2R7d53qhHhD75w1CKtRoHkp/NUVJkapQ 8JAywuGoBcz3KWzViM9nFeuUfDlH2XdlX0/huuJ3Ky3Ap65S8Y94iuFflyzQ3g== Message-ID: <8679fea7-94ce-4a52-8e48-1a8cd0857fcb@vondra.me> Date: Wed, 20 Nov 2024 23:19:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Slot's restart_lsn may point to removed WAL segment after hard restart unexpectedly To: pgsql-hackers@lists.postgresql.org References: <1d12d2-67235980-35-19a406a0@63439497> <683f3c82-d38e-436d-88fd-27722af62005@vondra.me> Content-Language: en-US From: Tomas Vondra In-Reply-To: <683f3c82-d38e-436d-88fd-27722af62005@vondra.me> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-GND-Sasl: tomas@vondra.me List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 11/20/24 18:24, Tomas Vondra wrote: > > ... > > What confuses me a bit is that we update the restart_lsn (and call > ReplicationSlotsComputeRequiredLSN() to recalculate the global value) > all the time. Walsender does that in PhysicalConfirmReceivedLocation for > example. So we actually see the required LSN to move during checkpoint > very often. So how come we don't see the issues much more often? Surely > I miss something important. > This question "How come we don't see this more often?" kept bugging me, and the answer is actually pretty simple. The restart_lsn can move backwards after a hard restart (for the reasons explained), but physical replication does not actually rely on that. The replica keeps track of the LSN it received (well, it uses the same LSN), and on reconnect it sends the startpoint to the primary. And the primary just proceeds use that instead of the (stale) restart LSN for the slot. And the startpoint is guaranteed (I think) to be at least restart_lsn. AFAICS this would work for pg_replication_slot_advance() too, that is if you remember the last LSN the slot advanced to, it should be possible to advance to it just fine. Of course, it requires a way to remember that LSN, which for a replica is not an issue. But this just highlights we can't rely on restart_lsn for this purpose. (Apologies if this repeats something obvious, or something you already said, Vitaly.) regards -- Tomas Vondra