Dirty replication slots when using 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. Craig Ringer Branch ------ master Details ------- http://git.postgresql.org/pg/commitdiff/d851bef2d60ff9345249ff67c053e37fe4b364cc Modified Files -------------- src/backend/replication/logical/logicalfuncs.c | 15 ++++++++++ src/test/recovery/Makefile | 2 ++ src/test/recovery/t/006_logical_decoding.pl | 40 ++++++++++++++++++++++++++ 3 files changed, 57 insertions(+) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
