What causes "Invalid Well-Known Binary (WKB)" in prestodb/presto?

Validate the input is genuine WKB before parsing (starts with 0x00/0x01 byte-order flag, plausible length)

INVALID_FUNCTION_ARGUMENT

INVALID_FUNCTION_ARGUMENT

Error message

Invalid Well-Known Binary (WKB)

What it means

GeometryUtils.stGeomFromBinary() parses a varbinary as a Well-Known Binary (WKB) geometry via ESRI's fromBinary(). If parsing throws IllegalArgumentException or IndexOutOfBoundsException, it is rethrown as PrestoException(INVALID_FUNCTION_ARGUMENT, "Invalid Well-Known Binary (WKB)").

Source

Thrown at presto-base-jdbc/src/main/java/com/facebook/presto/plugin/jdbc/GeometryUtils.java:45

public class GeometryUtils
{
    private GeometryUtils() {}

    public static Slice getAsText(Slice input)
    {
        return utf8Slice(wktFromJtsGeometry(deserialize(input)));
    }

    public static Slice stGeomFromBinary(Slice input)
    {
        requireNonNull(input, "input is null");
        OGCGeometry geometry;
        try {
            geometry = fromBinary(input.toByteBuffer().slice());
        }
        catch (IllegalArgumentException | IndexOutOfBoundsException e) {
            throw new PrestoException(INVALID_FUNCTION_ARGUMENT, "Invalid Well-Known Binary (WKB)", e);
        }
        geometry.setSpatialReference(null);
        return serialize(geometry);
    }
}

View on GitHub (pinned to 55bb57d202)

Solutions

Validate the input is genuine WKB before parsing (starts with 0x00/0x01 byte-order flag, plausible length)
Use st_is_valid or try the conversion on sample data to locate corrupt rows
Fix upstream producers so only WKB geometry bytes are written to the column
Convert non-standard formats (e.g. PostGIS EWKB) to plain WKB before loading

Example fix

// before
SELECT st_geometry_from_binary(payload) FROM raw.shapes; -- payload is not WKB
// after
SELECT st_geometry_from_binary(st_as_binary(st_geometry_from_text(wkt))) AS geom
FROM raw.shapes WHERE is_wkb(payload); -- parse only validated geometry bytes

Defensive patterns

Strategy: validation

Validate before calling

// Validate a buffer looks like WKB before parsing
boolean looksLikeWkb(byte[] b) {
    if (b == null || b.length < 5) return false;
    byte order = b[0];                      // 0x00 (big-endian) or 0x01 (little-endian)
    if (order != 0 && order != 1) return false;
    int type = ByteBuffer.wrap(b, 1, 4).order(order == 0 ? BIG_ENDIAN : LITTLE_ENDIAN).getInt();
    return type >= 1 && type <= 7;          // point..geometryCollection
}

Try / catch

try {
    geometry = st_geometry_from_binary(blob);
} catch (PrestoException e) {
    if (e.getErrorCode() == INVALID_FUNCTION_ARGUMENT.toErrorCode()) {
        log.warn("Skipping non-WKB blob at row {}", rowId); // filter or quarantine bad rows
    } else throw e;
}

Prevention

Validate input bytes with st_is_valid / geometry functions before calling WKB parsers in production queries
Ensure ETL writes only WKB produced by st_as_binary into geometry columns
Convert PostGIS EWKB to plain WKB before loading into Presto

When it happens

Trigger: Calling st_geometry_from_binary(blob) (or the connector's geometry functions) with bytes that are not valid WKB: truncated data, wrong endianness/flag byte, or non-geometry binary such as a hash or serialized payload.

Common situations: Storing arbitrary binary in a column later parsed as geometry; WKB produced by a tool with a different SRID/encoding convention; data truncated by an upstream ETL step; passing EWKB (PostGIS) with unsupported flags to the strict parser.

Related errors

AI-assisted analysis of prestodb/presto@55bb57d202 (2026-09-04). Data as JSON: /api/errors/aba4abcb656d2348. Report an issue: GitHub.