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
@@ -328,7 +328,10 @@ pg_logical_slot_get_changes_guts(FunctionCallInfo fcinfo, bool confirm, bool bin
if (ctx->reader->EndRecPtr != InvalidXLogRecPtr && confirm)
/* free context, call shutdown callback */
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: