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
Duncan Sands
Danila Kiver
Naci Ishakbeyoglu
Alexander Kukushkin
Horia Chiorean
Xavier Stevens
Jarred Ward