Skip to main content
Question

PostgreSQL bytea data is not written correctly by FeatureWriter (PostgreSQL → PostgreSQL)

  • October 5, 2026
  • 1 reply
  • 112 views

dbosyi
Participant
Forum|alt.badge.img

Hi,

I’m using FME Workbench (2025.1.3.3) to transfer data between different databases.

The workflow is as follows:

Creator → FeatureReader → DatabaseQuerier → FeatureWriter

The FeatureReader reads one feature from the source database to initialize the process. The DatabaseQuerier then executes a query against the source PostgreSQL database and returns the actual data to be written. The schema attributes are passed through the workflow, and the FeatureWriter writes the resulting features to an existing table in the destination PostgreSQL database.

The problem occurs when one of the source columns has the PostgreSQL bytea data type.

The source and destination tables have the following relevant column:

geom bytea

When both the source and destination databases are PostgreSQL, FME does not appear to transfer this binary attribute correctly.

With Bulk Insert enabled, the FeatureWriter fails with the following PostgreSQL error:

ERROR: missing data for column "geom"

The log also reports:

Bulk copy failed ... using delimiter ':'

If I disable Bulk Insert, the workspace completes successfully without any errors, but the geom column in the destination table contains NULL instead of the original binary data.

What makes this particularly interesting is that essentially the same workflow works correctly when the source database is Microsoft SQL Server and the destination is PostgreSQL. In that case, a SQL Server varbinary(max) column is transferred correctly and written to the PostgreSQL bytea column.

Therefore, the issue seems to be specific to handling PostgreSQL bytea values somewhere between DatabaseQuerier and FeatureWriter, rather than to the destination PostgreSQL bytea column itself.

I suspect that there may be an issue with how the PostgreSQL reader/querier exposes the binary value to FME, or how the PostgreSQL writer serializes it for COPY/bulk insert.

Has anyone encountered this behavior with PostgreSQL bytea attributes?

Any suggestions on how to resolve this issue would be greatly appreciated.

1 reply

veronikaatsafe
Safer
Forum|alt.badge.img+11

Hi dbosyi,

I looked into this and was able to reproduce both symptoms you described, the bulk copy failure and the silent NULL, and I found the root cause.

Your bytea column is named "geom", which happens to be the PostGIS community convention for naming the geometry column in a spatial table, and FME's PostgreSQL writer treats a column named "geom" as the reserved spatial column by default, regardless of its actual data type. Since your feature does not carry real FME geometry, just a binary attribute that happens to share that name, the writer excludes it from normal attribute writing entirely. With Bulk Insert enabled, this shows up as the bulk copy failure you saw, since the data line ends up with fewer values than the table has real columns. With Bulk Insert disabled, the writer instead silently writes NULL into that column while any other attributes you are writing continue to work normally, which matches what you reported.

The workaround: rename the column to something that is not a default spatial column name, for example geom_data or binary_payload, on both the source and destination tables (or just the destination, with an alias in your query). In my testing, this fully resolved both the bulk insert failure and the NULL behavior with no other changes needed.

Hope this helps. I will update this thread if I come across any changes in this workflow!