Running 'mvn clean verify' for vitess connector (which includes launch docker for integration tests) would fail when run on an Mac M1 laptop:
[*ERROR*] Failed to execute goal io.fabric8:docker-maven-plugin:0.31.0:build (start) on project debezium-connector-vitess: Execution start of goal io.fabric8:docker-maven-plugin:0.31.0:build failed: An API incompatibility was encountered while executing io.fabric8:docker-maven-plugin:0.31.0:build: java.lang.UnsatisfiedLinkError: could not load FFI provider jnr.ffi.provider.jffi.Provider
The problem is specific to Apple M1 laptop, and is discussed further in: https://github.com/fabric8io/docker-maven-plugin/issues/1257
This is already fixed in docker-maven-plugin 0.39.1
With proposed changes empty arrays are skipped, as it allows us to delay defining the schema for them until an array with elements is found, as it seems that there is no way to modify a schema that was already defined for a given field
Postgres supports partitioned tables. Debezium requires tables to have
primary key to be able to snapshot them. Primary key support for
partitioned was added in Postgres 11, see [1]. Add partitioned table
type into supported table tables so that Debezium fetches the schema
and can do the snapshot for partitioned tables.
N.B.: On Postgres < 11 is still possible to define primary key
constraint on partitioned sub-tables. In such cases sub-tables are
snapshotted, but parent table is not.
Fix RecordsSnapshotProducerIT#shouldGenerateSnapshotsForPartitionedTables
test after adding support for partitioned tables. Test assumed that
the parent table is not snapshotted and filters out duplicate records
which results into lossing `LAST` snapshot record. Keepting original
test by filtering parent table.
[1] https://www.postgresql.org/docs/11/release-11.html
Assertion would fail if one or both of the scenario occurs
1) Deadlock between Writer and Reader Threads
2) Thread Starvation between Writer and Reader Threads
When enabling the `database.history.store.only.captured.tables.ddl`,
the logging in RelationalSnapshotChangeEventSource does not take into
account this setting when logging, leading to a false impression of
what tables will actually be captured in the schema history.
