Feedback-ID: ia2694551:Fastmail
Date: Mon, 6 Feb 2023 16:22:09 +0100
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: depesz@depesz.com, Amit Kapila <amit.kapila16@gmail.com>,
	PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: WAL segments removed from primary despite the fact that logical
 replication slot needs it.
Message-ID: <20230206152209.yglmntznhcmaueyn@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAD21AoBG2OSDOFTtpPtQ7fx5Vt8p3dS5hPAv28CBSC6z2kHx-g@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/20230206152209.yglmntznhcmaueyn%40alvherre.pgsql>
Precedence: bulk

On 2023-Feb-06, Masahiko Sawada wrote:

> I've also confirmed that this issue is fixed by the attached patch,
> which clears candidate_restart_lsn and friends during
> ReplicationSlotRelease().

Hmm, interesting -- I was studying some other bug recently involving the
xmin of a slot that had been invalidated and I remember wondering if
these "candidate" fields were being properly ignored when the slot is
marked not in use; but I didn't check.  Are you sure that resetting them
when the slot is released is the appropriate thing to do?  I mean,
shouldn't they be kept set while the slot is in use, and only reset if
we destroy it?

(But, actually, in that case, maybe we don't need to reset them: instead
we need to make sure to ignore the values for slots that are not in_use.
However, I don't know what the semantics are for these "candidate"
fields, so maybe this is wrong.)

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/