• Simon Riggs's avatar
    Dirty replication slots when using sql interface · d851bef2
    Simon Riggs authored
    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
    d851bef2
logicalfuncs.c 10.7 KB