This code was effectivelly dead. It was used only when PostGIS geometry type was created inside the public schema and was responsible for translating of PostGIS point to PG point. When we introduced the full support for PostGIS types in Debezium the code was no longer used as PostGIS types are typically created in separate schema.
So now we support
* POINT type (postgres point)
* postgis GEOMETRY in arbitrary schema (including geometry point)
as WARNING messages are transmitted all the way to the client (i.e. are costly).
In my case I have lots of tables with types that aren't yet understood by
decoderbufs. These tables aren't being monitored, but because logical decoding
works on the level of the entire database, not just the tables monitored, rows
from them are still reaching decoderbufs, generating vast numbers of warnings
"Encountered unknown typid..."
Likewise, I have many unmonitored materialized views. Every row deleted when
doing a concurrent refresh generates the warning
"...no PK is present..."
These warnings cause two types of trouble when they hit the debezium postgres
connector: a memory leak and increased CPU usage. The memory leak is because
the JDBC layer carefully preserves these warnings in a list, and the list is
never being cleared (this should be fixed in the connector). As for the CPU
usage, I don't fully understand why the processing time increases so much.
It's normal that it should double, as there are twice as many packets to
process (one warning for every row), but it seems to take way more than twice
as long.
Jiri Pechanec
Gunnar Morling
Alexander Kukushkin
Duncan Sands
Danila Kiver
Naci Ishakbeyoglu
Horia Chiorean
Xavier Stevens
Jarred Ward