Hi all

Currently replication slots are not dirtied when the client sends
confirmation of replay. So when we checkpoint we don't bother writing out
the updated slot state unless the restart_lsn has also changed as a result
of the replay confirmation.

That's pretty fuss free for the walsender interface, but for the SQL
interface it means that pg_logical_slot_get_changes() will repeat changes
you've already seen after a restart. Even if you did a clean shutdown.

I think that's a bit ugly, and I propose a trivial change to dirty the
replication slot from pg_logical_slot_get_changes_guts(...) if called in
get mode not peek mode. That way it'll get written out next time we
checkpoint the slot state.

The current behaviour isn't a data loss risk, and apps have to be prepared
for this to happen anyway on unclean exit. So this is mostly
convenience/cosmetic; I'll add it to the first 9.7 CF.

-- 
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services
From d31ab118ee6689503bac1a3d308677a9742180b5 Mon Sep 17 00:00:00 2001
From: Craig Ringer <cr...@2ndquadrant.com>
Date: Mon, 2 May 2016 19:50:22 +0800
Subject: [PATCH] Dirty replication slots from SQL decoding interface

---
 src/backend/replication/logical/logicalfuncs.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/backend/replication/logical/logicalfuncs.c b/src/backend/replication/logical/logicalfuncs.c
index 84b4d57..8b32f02 100644
--- a/src/backend/replication/logical/logicalfuncs.c
+++ b/src/backend/replication/logical/logicalfuncs.c
@@ -328,7 +328,10 @@ pg_logical_slot_get_changes_guts(FunctionCallInfo fcinfo, bool confirm, bool bin
 		 * business..)
 		 */
 		if (ctx->reader->EndRecPtr != InvalidXLogRecPtr && confirm)
+		{
 			LogicalConfirmReceivedLocation(ctx->reader->EndRecPtr);
+			ReplicationSlotMarkDirty();
+		}
 
 		/* free context, call shutdown callback */
 		FreeDecodingContext(ctx);
-- 
2.5.5

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to