Hello, In LogicalConfirmReceivedLocation two fields (data.catalog_xmin and effective_catalog_xmin) of ReplicationSlot structure are used for advancing xmin of the slot. This allows to avoid hole when tuples might already have been vacuumed, but slot's state was not yet flushed to the disk: if we crash during this hole, after restart we would assume that all tuples with xmax > old catalog_xmin are still there, while actually some of them might be already vacuumed. However, the same dodge is not used for restart_lsn advancement. This means that under somewhat unlikely circumstances it is possible that we will start decoding from segment which was already recycled, making the slot broken. Shouldn't this be fixed?
-- Arseny Sher Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
