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(+)