Re: Making the ENUM operators LEAKPROOF
Laurenz Albe <laurenz.albe@cybertec.at>
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: pgsql-hackers@lists.postgresql.org
Date: 2026-05-10T17:43:45Z
Lists: pgsql-hackers
Attachments
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