pgcopydb follow leads to startpos being updated in sentinal as streaming continues

[kevinnowland]

I attempted to use the following commands to do an online migration and am seeing the sentinel startpos update mid-migration. Is this expected?

I start with pgcopydb snapshot --follow --dir $TMPDIR/pgcopydb which gives the following (sample) output:

TIMESTAMP INFO Running pgcopydb version 0.17-1.pgdg22.04+1 from "/usr/bin/pgcopydb"
TIMESTAMP INFO Using work dir $TMPDIR/pgcopydb
TIMESTAMP INFO Created logical replication slot "pgcopydb" with plugin "test_decoding" at SOME_LSN and exported snapshot SOME_SNAPSHOT

Then in another terminal we run pgcopydb follow --dir $TMPDIR/pgcopydb and this reports that

TIMESTAMP INFO Running pgcopydb version 0.17-1.pgdg22.04+1 from "/usr/bin/pgcopydb"
TIMESTAMP INFO [SOURCE] Copying database from "SOURCE_CONNECTION_STRING"
TIMESTAMP INFO [TARGET] Copying database into "TARGET_CONNECTION_STRING"
TIMESTAMP INFO Using work dir $TMPDIR/pgcopydb
TIMESTAMP INFO Re-using replication slot "pgcopydb" created at SOME_LSN with snapshot SOME_SNAPSHOT
TIMESTAMP INFO Created logical replication origin "pgcopydb" at LSN SOME_LSN

Where SOME_LSN matches in all cases.

Running pgcopydb stream sentinel get initial will report startpos at SOME_LSN matching the above. But, as changes come in, if we re-run pgcopydb stream sentinel get we see that the LSN reported at startpos no longer matches and is instead updated alongside write_lsn and flush_lsn.

Is this expected behavior? My expectation is that the startpos should be static while write_lsn, flush_lsn, and, eventually, replay_lsn should change over time.

Thank you!

[kevinnowland]

The same behavior happens if I instead simply run the command

pgcopydb clone \
  --follow \
  --restore-jobs 16 \
  --table-jobs 16 \
  --large-objects-jobs \
  --index-jobs 1 \
  --no-owner \
  --no-acl

If I run pgcopydb stream sentinel get --startpos, the startpos is incrementing.