From 7261d4e182a011c8bb609f9307dcc61c5e15dd56 Mon Sep 17 00:00:00 2001 From: Craig Ringer Date: Mon, 2 May 2016 19:50:22 +0800 Subject: [PATCH] Dirty replication slots when accessed via sql interface When pg_logical_slot_get_changes(...) sets confirmed_flush_lsn to the point at which replay stopped, it doesn't dirty the replication slot. So if the replay didn't cause restart_lsn or catalog_xmin to change as well, this change will not get written out to disk. Even on a clean shutdown. If Pg crashes or restarts, a subsequent pg_logical_slot_get_changes(...) call will see the same changes already replayed since it uses the slot's confirmed_flush_lsn as the start point for fetching changes. The caller can't specify a start LSN when using the SQL interface. Mark the slot as dirty after reading changes using the SQL interface so that users won't see repeated changes after a clean shutdown. Repeated changes still occur when using the walsender interface or after an unclean shutdown. --- 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 4e4c8cd..3d1de03 100644 --- a/src/backend/replication/logical/logicalfuncs.c +++ b/src/backend/replication/logical/logicalfuncs.c @@ -321,7 +321,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