Re: Making the ENUM operators LEAKPROOF

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Making the ENUM operators LEAKPROOF
Date: 2026-05-10 17:43:45
Message-ID: 8e03e63c85f7fd8f5eb3209df493f0d7dc2d26c1.camel@cybertec.at
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 2026-04-29 at 17:32 +0200, Laurenz Albe wrote:
> This is an attempt to get the operators from the "enum_ops" operator
> class LEAKPROOF.
>
> [...]
>
> One particular case that I want to discuss is out-of-memory conditions.
> Some of the OOM error messages show the allocation size that failed
> (dshash.c, mbutils.c, dsa.c and mcxt.c), which could leak some
> information about the data involved. My feeling is that that is
> something you cannot exploit just by using an application; you'd have
> to cause just the right memory pressure to make small allocations fail.
> (If we decide to err on the side of caution here, I'd actually prefer
> to have the error messages changed to not reveal the allocation size.)

I have become even less worried about that case after seeing that the
"text" comparison functions are leakproof. With "text", one could argue
that you could trigger an OOM error by comparing with a value you don't
know, if that value has to be detoasted. That way, you could know the
length of the unknown string. If "text" is considered safe enough, I
don't think we need to worry about enum_cmp(), which doesn't even have
that problem.

I prepared a patch so that I can add the thread to the next commitfest.

Yours,
Laurenz Albe

Attachment Content-Type Size
v1-0001-Mark-the-enum-comparison-functions-as-leakproof.patch text/x-patch 3.4 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sergey Glushchenko 2026-05-10 19:58:11 [PATCH] contrib/oid2name: add TAP tests for object listing
Previous Message Marcos Pegoraro 2026-05-10 16:49:51 Missing jsonb_ ... functions on DOCs