Re: PostgreSQL 18 beta1 - Segmentation fault on custom type casting

Thank you, Aleksander and Tom!

I ended up using JSONB instead of a custom datatype. The actual work
involves an iCal extension written in C. I'm not fluent in C or PostgreSQL
internals. The iCal library stores pointers in its struct, and serializing
and saving that caused the first seg fault because the pointer was no
longer valid. Then I tried the custom datatype using varlena and
encountered a type-casting issue. That led me to realize my custom datatype
used offsets for each part of the iCal properties and stored this in the
varlena header. However, when PostgreSQL processes this binary data, it
arranges it in the most efficient order, making the offsets in the header
point to the wrong data.

Regards,

Thomas

------------------------------
Hi Aleksander and Tom,

Thank you for your help.

I ended up using JSONB instead of a custom data type. The actual work
involves an iCal extension written in C. I'm not fluent in C or PostgreSQL
internals, which led to a few challenges.

Initially, I encountered a segmentation fault because the iCal library
stores pointers in its struct, and serializing and saving that caused the
pointer to become invalid.

Then, when I tried to implement a custom data type using `varlena`, I ran
into a type-casting issue. This made me realize that my custom data type
was using offsets for each part of the iCal properties and storing these in
the `varlena` header. However, when PostgreSQL processes this binary data,
it rearranges it for efficiency, causing the offsets in the header to point
to the wrong data.

Regards,

Thomas

On Thu, Jul 10, 2025 at 7:55 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Thomas Thai <thomas(dot)t(dot)thai(at)gmail(dot)com> writes:
> > PostgreSQL 18 beta crashes with a segmentation fault when casting strings
> > to custom types. The crash occurs specifically in PostgreSQL's
> type-casting
> > system, not in extension code.
>
> The reason you're having a problem is that this is not a valid way to
> store a custom type. The representation has to be a single blob of
> memory [1], and it has to be represented in a way that lets
> type-independent code determine its length. Typically that means
> following the varlena-header rules.
>
> regards, tom lane
>
> [1] Well, there is a notion of an "expanded" representation that
> doesn't have to be a flat blob. But you're not following the
> rules for that either.
>