apache/seatunnel · warning

The length of binary column {} is {}, which exceeds the maxi

Error message

The length of binary column {} is {}, which exceeds the maximum length of {}, the length will be set to {}

What it means

WARN log from RedshiftTypeConverter.reconvert. When a BINARY (BYTES) column's length exceeds Redshift's MAX_BINARY_VARYING_LENGTH, the converter clamps the column type to VARBINARY(MAX_BINARY_VARYING_LENGTH) instead of failing. Data longer than the clamp may be truncated or rejected by the database.

Source

Thrown at seatunnel-connectors-v2/connector-jdbc/src/main/java/org/apache/seatunnel/connectors/seatunnel/jdbc/internal/dialect/redshift/RedshiftTypeConverter.java:333

                break;
            case BYTES:
                if (column.getColumnLength() == null || column.getColumnLength() <= 0) {
                    builder.columnType(
                            String.format(
                                    "%s(%d)", REDSHIFT_BINARY_VARYING, MAX_BINARY_VARYING_LENGTH));
                    builder.dataType(REDSHIFT_BINARY_VARYING);
                } else if (column.getColumnLength() <= MAX_BINARY_VARYING_LENGTH) {
                    builder.columnType(
                            String.format(
                                    "%s(%d)", REDSHIFT_BINARY_VARYING, column.getColumnLength()));
                    builder.dataType(REDSHIFT_BINARY_VARYING);
                    builder.length(column.getColumnLength());
                } else {
                    builder.columnType(
                            String.format(
                                    "%s(%d)", REDSHIFT_BINARY_VARYING, MAX_BINARY_VARYING_LENGTH));
                    builder.dataType(REDSHIFT_BINARY_VARYING);
                    log.warn(
                            "The length of binary column {} is {}, which exceeds the maximum length of {}, "
                                    + "the length will be set to {}",
                            column.getName(),
                            column.getColumnLength(),
                            MAX_BINARY_VARYING_LENGTH,
                            MAX_BINARY_VARYING_LENGTH);
                }
                break;
            case TIME:
                Integer timeScale = column.getScale();
                if (timeScale != null && timeScale > MAX_TIME_SCALE) {
                    timeScale = MAX_TIME_SCALE;
                    log.warn(
                            "The time column {} type time({}) is out of range, "
                                    + "which exceeds the maximum scale of {}, "
                                    + "it will be converted to time({})",
                            column.getName(),
                            column.getScale(),

View on GitHub (pinned to cf67b549a7)

Solutions

1. Reduce or declare a smaller binary column length upstream so it fits within MAX_BINARY_VARYING_LENGTH
2. Pre-create the Redshift table with the desired VARBINARY/BINARY column definition
3. Accept the clamp; confirm actual payloads fit within MAX_BINARY_VARYING_LENGTH bytes

Example fix

// before: binary column 'payload' with length 2000000000
// after: pre-create the sink table
// CREATE TABLE target (payload VARBINARY(1000000));

if (col.getColumnLength() != null && col.getColumnLength() > maxBinaryVaryingLength) {
    // shrink or drop the binary column before the sink
}

boolean fitsRedshiftBinaryLength(CatalogColumn col, long max) {
    return col.getColumnLength() == null || col.getColumnLength() <= max;
}

When it happens

Trigger: Auto-creating a Redshift table from a catalog where a binary column's getColumnLength() exceeds MAX_BINARY_VARYING_LENGTH; raised in reconvert() during type mapping.

Common situations: Ingesting large blobs/bytea from sources that declare unlimited binary length (e.g. Kafka byte arrays, file-based sources) into Redshift with auto table creation.

Understand the failure class

Background: "value must be between 0 and 1" / "out of range" / "must not be negative" errors: fixing range-validation failures across open-source libraries — this error's family across 42 libraries.

Related errors

• COMMON-17
• COMMON-19
• The decimal column {} type decimal({},{}) is out of range, w
• The length of string column {} is {}, which exceeds the maxi
• The time column {} type time({}) is out of range, which exce

AI-assisted analysis of apache/seatunnel@cf67b549a7 (2026-09-10). Data as JSON: /api/errors/b82f721fc02212b1. Report an issue: GitHub.