From: Amit Kapila <akapila@postgresql.org>
Date: Tue, 11 Jun 2024 05:21:34 +0000 (+0530)
Subject: Fix an assert in CheckPointReplicationSlots().
X-Git-Tag: REL_17_BETA2~70
X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=d1ffcc7fa3c54de8b2a677a3e503fc808c7b419c;p=thirdparty%2Fpostgresql.git

Fix an assert in CheckPointReplicationSlots().

Commit e0b2eed047 assumed that the confirmed_flush LSN can't go backward.
However, it is possible that confirmed_flush LSN can go backward
temporarily when the client acknowledges a prior value of flush location.
This can happen when the client (subscriber in this case) acknowledges an
LSN it doesn't have to do anything for (say for DDLs) and thus didn't
store persistently. After restart, the client sends the prior value of
flush LSN which it had stored persistently and the server updates the
confirmed_flush LSN with that value.

The fix is to remove the assumption and not allow the prior value of
confirmed_flush LSN to be flushed to the disk.

Author: Vignesh C
Reviewed-by: Amit Kapila, Shlok Kyal
Discussion: https://postgr.es/m/CALDaNm3hgow2+oEov5jBk4iYP5eQrUCF1yZtW7+dV3J__p4KLQ@mail.gmail.com
---

diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c
index 0e54ea5bb9a..564cfee1270 100644
--- a/src/backend/replication/slot.c
+++ b/src/backend/replication/slot.c
@@ -1874,10 +1874,8 @@ CheckPointReplicationSlots(bool is_shutdown)
 		{
 			SpinLockAcquire(&s->mutex);
 
-			Assert(s->data.confirmed_flush >= s->last_saved_confirmed_flush);
-
 			if (s->data.invalidated == RS_INVAL_NONE &&
-				s->data.confirmed_flush != s->last_saved_confirmed_flush)
+				s->data.confirmed_flush > s->last_saved_confirmed_flush)
 			{
 				s->just_dirtied = true;
 				s->dirty = true;