Normally when a connector gracefully shuts down, the connect framework attempts to commit offsets so the latest committed state gets acked on the replication stream. While the connector is running, the framework periodically commits offsets. Debezium does not manage triggering an offset commit. When the catch up streaming phase ends, there may be uncommitted state and the connector is unable to determine when the next commit will occur because the commit timing is externally managed. If a commit is not triggered between the end of the catch up streaming phase and the normal streaming phase after the snapshot, the connector may produce some duplicated messages.
Although the replication stream may be out of date, the internal OffsetContext is aware of the latest committed offset. When the snapshot phase recreates a new offset after catch up streaming, the previous offset has access to the latest state. Use the previous offset to forward known state to the new offset.
When a connector resumes after previously streaming and takes a
snapshot, through a new method on the snapshotter interface,
shouldStreamEventsStartingFromSnapshot, can choose whether
to resume streaming from the last known streaming position or the
beginning of the snapshot. This is helpful for snapshotters that
may not want to resnapshot every table in the whitelist/blacklist
but not miss event on the tables that are skipped.
This is called only once anyways, so there's no need for storing the info
in a field in PostgresConnection. This allows PostgresConnector#validate()
bring up a more meaningful error message in case of incorrect credentials
and other incorrect connection configuration.
* removed little endian padding for BIT types in JdbcValueConverters (only used for Postgres yet)
* removed legacy format handling fot BIT related types in JdbcValueConverters#convertBits which were leftovers from PR #1408
* removed unnecessary zero-ing of a newly created byte array to improve performance for huge byte arrays
* updated Postgres connector docs
See https://issues.redhat.com/browse/DBZ-2310 for more explanation.
Short summary: Whenever LSNs are skipped return back that messages have
been processed, which will cause two things:
* The replication can be advanced properly
* The connector does not fallback to the poll timeout waiting interval
I also think its more correct to say, "yes I have read messages, but
still skipped all of them".
