Fix consistency issues with replication slot copy
Commit 9f06d79ef831's replication slot copying failed to
properly reserve the WAL that the slot is expecting to see
during DecodingContextFindStartpoint (to set the confirmed_flush
LSN), so concurrent activity could remove that WAL and cause the
copy process to error out. But it doesn't actually *need* that
WAL anyway: instead of running decode to find confirmed_flush, it
can be copied from the source slot. Fix this by rearranging things
to avoid DecodingContextFindStartpoint() (leaving the target slot's
confirmed_flush_lsn to invalid), and set that up afterwards by copying
from the target slot's value.
Also ensure the source slot's confirmed_flush_lsn is valid.
Reported-by: Arseny Sher
Author: Masahiko Sawada, Arseny Sher
Discussion: https://postgr.es/m/871rr3ohbo.fsf@ars-thinkpad
Branch
------
REL_12_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/e58e13e846953e0540b1a2c9a7739b666e134997
Modified Files
--------------
src/backend/replication/logical/logical.c | 2 ++
src/backend/replication/slotfuncs.c | 46 ++++++++++++++++++++++++++-----
2 files changed, 41 insertions(+), 7 deletions(-)