Which use case/requirement will be addressed by the proposed feature?

Transient failures of `TOAST` re-selection:

WARN [debezium-postgresconnector-{}-change-event-source-coordinator] [{}|{}] Failed to re-select row for table {} and key {} (io.debezium.processors.reselect.ReselectColumnsPostProcessor)
org.postgresql.util.PSQLException: An I/O error occurred while sending to the backend.
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:395)
at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:498)
at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:415)
at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:190)
at org.postgresql.jdbc.PgPreparedStatement.executeQuery(PgPreparedStatement.java:134)
at io.debezium.jdbc.JdbcConnection.prepareQuery(JdbcConnection.java:808)
at io.debezium.jdbc.JdbcConnection.reselectColumns(JdbcConnection.java:1672)
...
Caused by: java.net.SocketException: Connection reset
at java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:328)
at java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:355)
at java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:808)
at java.base/java.net.Socket$SocketInputStream.read(Socket.java:966)

There's currently no retry strategy. You have to perform a snapshot of the affected table as and when these failures occur.

One workaround seems to be the use of the undocumented `custom.retriable.exception` property e.g. `Failed to re[-]select row`.

Implementation ideas (optional)

If it doesn't make sense to implement retries for the Post Processors as code, the existing undocumented property `custom.retriable.exception` seems to provide a stable workaround.

Failing that, https://github.com/debezium/debezium/pull/5944 introduced error handling modes, can that be leveraged in conjunction with `errors.max.retries`?