[Bug] postgres-16-postgis geometry字段在CDC同步时会直接报错，无法被排除

[fine-1]

Search before asking

• I had searched in the issues and found no similar issues.

Version

4.1.3 lastest

What's Wrong?

我的pgsql数据库使用了postgis插件，该插件引入了新的数据类型，其中我有一些表使用了geomtry这一几何类型字段，该字段在cdc同步时会先报错类型不支持，从而导致“exclude_columns”排除参数无法生效。

以下排除可以对不含geometry类型的pgsql库表生效
CREATE JOB pg_szt_cdc
ON STREAMING
FROM POSTGRES (
"jdbc_url" = "jdbc:postgresql://192.168.1.100:5432/test",
"driver_url" = "postgresql-42.7.x.jar",
"driver_class" = "org.postgresql.Driver",

"user" = "doris_cdc",
"password" = "你的密码",

"database" = "test",
"schema" = "public",

"include_tables" =
 "person,people",

"table.person.exclude_columns" = "name",
"table.people.exclude_columns" = "name",

"offset" = "initial"

)
TO DATABASE szt_ods (
"table.create.properties.replication_num" = "1"
);

以下排除可以对含geometry类型的pgsql库表不生效，无法正常执行
CREATE JOB pg_szt_cdc
ON STREAMING
FROM POSTGRES (
"jdbc_url" = "jdbc:postgresql://192.168.1.100:5432/test",
"driver_url" = "postgresql-42.7.x.jar",
"driver_class" = "org.postgresql.Driver",

"user" = "doris_cdc",
"password" = "你的密码",

"database" = "test",
"schema" = "public",

"include_tables" =
 "building",

"table.building.exclude_columns" = "geometry",

"offset" = "initial"

)
TO DATABASE szt_ods (
"table.create.properties.replication_num" = "1"
);

building表结构如下：
/*
Navicat Premium Data Transfer

Source Server : 192.168.1.100test
Source Server Type : PostgreSQL
Source Server Version : 160013 (160013)
Source Host : 192.168.1.100:5432
Source Catalog : tp_szt
Source Schema : public

Target Server Type : PostgreSQL
Target Server Version : 160013 (160013)
File Encoding : 65001

Date: 03/09/2026 17:06:05
*/

---

-- Table structure for building

---

DROP TABLE IF EXISTS "public"."building";
CREATE TABLE "public"."building" (
"id" int8 NOT NULL,
"buildingid" int8 NOT NULL,
"buildingdata" jsonb,
"buildingclass" int8,
"buildingname" varchar(255) COLLATE "pg_catalog"."default",
"geometry" geometry(GEOMETRYCOLLECTION, 4326),
"create_by" varchar(32) COLLATE "pg_catalog"."default",
"create_time" timestamp(6),
"update_by" varchar(32) COLLATE "pg_catalog"."default",
"update_time" timestamp(6),
"processdata" jsonb,
"lng" numeric(16,8),
"lat" numeric(16,8)
)
;
COMMENT ON COLUMN "public"."building"."buildingid" IS '3D建筑模型的ID';
COMMENT ON COLUMN "public"."building"."buildingdata" IS '3D建筑模型的geojosn数据';
COMMENT ON COLUMN "public"."building"."buildingclass" IS '类别';
COMMENT ON COLUMN "public"."building"."buildingname" IS '3D建筑模型的名称';
COMMENT ON COLUMN "public"."building"."geometry" IS '面数据';
COMMENT ON COLUMN "public"."building"."create_by" IS '创建人';
COMMENT ON COLUMN "public"."building"."create_time" IS '创建时间';
COMMENT ON COLUMN "public"."building"."update_by" IS '更新人';
COMMENT ON COLUMN "public"."building"."update_time" IS '更新时间';
COMMENT ON COLUMN "public"."building"."processdata" IS 'mvt数据';

---

-- Indexes structure for table building

---

CREATE INDEX "buildingid_building_index" ON "public"."building" USING btree (
"buildingid" "pg_catalog"."int8_ops" ASC NULLS LAST
);
CREATE INDEX "geometry_building_index" ON "public"."building" USING gist (
"geometry" "public"."gist_geometry_ops_2d"
);
CREATE INDEX "id_building_index" ON "public"."building" USING btree (
"id" "pg_catalog"."int8_ops" ASC NULLS LAST
);
CREATE INDEX "st_buffer_building_index" ON "public"."building" USING gist (
st_buffer(geometry, 0::double precision) "public"."gist_geometry_ops_2d"
);

---

-- Primary Key structure for table building

---

ALTER TABLE "public"."building" ADD CONSTRAINT "building_origin_copy1_pkey" PRIMARY KEY ("id");

What You Expected?

能否调整排除优先级，让exclude_columns先与类型识别生效？
或者
对不支持或无法识别的数据类型统一默认为string，而不是直接失败？

How to Reproduce?

No response

Anything Else?

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[Doris-Breakwater]

Breakwater-GitHub-Analysis-Slot: slot_bc7e689d1154

Initial assessment

Triage: Confirmed code-level defect in the Doris 4.1.3 PostgreSQL CDC Streaming Job auto-table-creation path. The issue currently has no labels, assignee, or linked development work. Confidence is high from the 4.1.3 source path, although an end-to-end PostgreSQL 16/PostGIS reproduction was not run because the report does not include the actual exception or FE stack trace.

Verified facts

1. In 4.1.3, JdbcPostgreSQLClient.jdbcTypeToDoris has no geometry mapping. Its default branch returns Type.UNSUPPORTED.
2. During CREATE JOB, generateCreateTableCmds calls getColumns(...) before parsing and applying table.<table>.exclude_columns.
3. getColumns(...) rejects every UNSUPPORTED column immediately. Therefore table.building.exclude_columns = "geometry" cannot be reached in time to suppress the failure. The code implies the error should contain Unsupported column type, table:[building], column:[geometry]; the reporter's exact error is still needed to confirm that this is the observed exception.
4. The post-creation CDC paths already use the desired ordering: snapshot/incremental row serialization checks the exclusion before value conversion (code), and PostgreSQL schema-change handling skips an excluded added column before Doris type generation (code). Static tracing therefore localizes this report to initialization/target-schema generation; runtime behavior should still be covered by an integration test.
5. Current master contains pre-created target-table support from #66950, which bypasses source-to-Doris type conversion when the target table already exists. That change postdates 4.1.3 and is not present in the inspected branch-4.1 ref, so it is not a verified workaround for the reported release. The non-pre-created auto-creation path on master still validates unsupported types before filtering exclusions.

Recommended maintainer action

Prefer a targeted ordering fix rather than mapping every unknown PostgreSQL type to STRING:

• Parse exclude_columns before getColumns(...) performs unsupported-type validation.
• Fetch the source column metadata, validate excluded names against the complete name set, and continue rejecting excluded primary-key columns.
• Remove the explicitly excluded columns, then validate/map only the remaining columns to Doris types.
• Keep the existing failure for an unsupported column that is not excluded.

Globally defaulting all unrecognized extension types to STRING would change JDBC behavior beyond CDC and could silently misrepresent types whose wire/runtime representation is not safely string-compatible.

Suggested regression coverage:

• PostgreSQL/PostGIS table with id as the primary key and geometry geometry(GEOMETRYCOLLECTION, 4326) excluded: CREATE JOB succeeds and the Doris table omits geometry.
• The same source table without the exclusion still fails with a clear unsupported-column error.
• Existing validation for nonexistent and primary-key exclusions remains intact.
• Initial snapshot plus incremental INSERT/UPDATE/DELETE succeed while the PostGIS column is present.
• DROP/re-ADD of the excluded PostGIS column does not emit Doris DDL and does not stop the job.

A 4.1 backport should be considered after the fix is verified.

Information still needed from the reporter

• The complete SQL client error returned by CREATE JOB and the corresponding FE log stack trace.
• The full Doris build string (SELECT VERSION()), exact PostgreSQL JDBC driver version/artifact, PostgreSQL server version, and PostGIS version (SELECT postgis_full_version()).
• Confirmation of the actual source database: the job example uses test, while the exported DDL header names tp_szt.
• A minimal inserted row containing a non-null GEOMETRYCOLLECTION and whether the failure occurs synchronously during CREATE JOB or only after the job starts.